Scientific Annals of Computer Science vol. 26 (2), 2016, pp. 187—248 
doi: 10.7561/SACS.2016.2.187 


On Activation, Connection, and Behavior in 
Dynamic Architectures 


Diego MARMSOLER, Mario GLEIRSCHER! 


Abstract 


The architecture of a system describes the system’s overall orga- 
nization into components and connections between those components. 
With the emergence of mobile computing, dynamic architectures be- 
came increasingly important. In such architectures, components may 
appear or disappear, and connections may change over time. Despite 
the growing importance of dynamic architectures, the specification of 
properties for those architectures remains a challenge. To address this 
problem, we introduce the notion of configuration traces to model pro- 
perties of dynamic architectures. Then, we characterize activation, 
connection, and behavior properties as special sets of configuration 
traces. We then show soundness and relative completeness of our 
characterization, i.e., we show that the intersection of an activation, 
connection, and behavior property contains all relevant configuration 
traces and that (almost) every property can be separated into these 
classes. Configuration traces can be used to specify general properties 
of dynamic architectures and the separation into different classes provi- 
des a systematic way for their specification. To evaluate our approach 
we apply it to the specification and verification of the Blackboard ar- 
chitecture pattern. 
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1 Introduction 


A system’s architecture provides a set of components and connections bet- 
ween their ports. With the emergence of mobile computing, dynamic archi- 
tectures became more and more important [5, 11, 24]. In such architectures, 
components can appear and disappear and connections can change, both 
over time. 

Despite the increasing importance of dynamic architectures some que- 
stions regarding their specification still remain: 

e How can properties of dynamic architectures be specified in general? 

e How can those properties be separated into different classes? 
A property of dynamic architectures characterizes executions of such ar- 
chitectures. Consider, for example, the following property for a publisher- 
subscriber [9] system: Whenever a component p of type Publisher provides 
a message for which a Subscriber component s was subscribed, s is con- 
nected to p. Another example describes a property of a Blackboard archi- 
tecture [9]: Whenever a component of type BlackBoard provides a message 
containing a problem to be solved, a component of type KnowledgeSource, 
able to solve this problem, is eventually activated. Usually, such properties 
can be separated into different classes, such as: (i) Behavior properties cha- 
racterizing the behavior of certain components. (ii) Activation properties 
characterizing the activation/deactivation of components. (iii) Connection 
properties characterizing the dynamic connection between components. 

To answer the above questions, we first introduce a formal model of 
dynamic architectures. Thereby we model an architecture as a set of configu- 
ration traces which, in turn, are sequences over architecture configurations. 
An architecture configuration is modeled as a set of components, valuati- 
ons of the component ports with messages, and connections between these 
ports. 

In a second step, we characterize behavior, activation, and connection 
properties as sets of configuration traces fulfilling certain closure properties. 
Then, we show soundness of our characterization, i.e., that the intersection 
of a behavior, activation, and a connection property contains all configu- 
ration traces satisfying corresponding activation, connection, and behavior 
aspects, respectively. 

Moreover, we show relative completeness of our characterization. The- 
reby we characterize the notion of separable architecture property and show 
that each separable architecture property can be uniquely described through 
the intersection of a corresponding behavior, activation, and connection pro- 
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perty. 

As a practical implication of our findings, we propose a method to 
specify dynamic architectures, separating activation, connection, and beha- 
vioral aspects. Finally, we demonstrate the approach by specifying (and 
verifying) the Blackboard pattern for dynamic architectures. Therefore, we 
first specify behavior, activation, and connection properties for Blackboard 
architectures. Then, we specify the pattern’s guarantee as an architecture 
property. Finally, we verify the pattern by proving its guarantee from the 
original properties. 

The article is organized as follows: In the remainder of this section 
we discuss changes to a previous version of this paper and introduce the 
Blackboard pattern as a running example. Section 2 introduces our mo- 
del for dynamic architectures. Section 3 characterizes the different classes 
of properties and provides soundness and completeness results. Section 4 
presents an approach to systematically specify properties and applies it to 
specify the Blackboard pattern. In Section 5 we provide a critical discus- 
sion of possible weaknesses of the approach. Section 6 discusses relations 
to existing work and Sect. 7 summarizes our results and discusses potential 
implications and future work. In App. A we provide full proofs of all the 
lemmata and theorems provided in the paper. 


1.1 Previously Published Material 


This paper is an extended version of Marmsoler and Gleirscher [23]. It 
provides improvements in the definition of some of the concepts already 
introduced in [23] and also provides some new concepts. In particular we 
introduced the crucial concept of mergeable architectures (Def. 11) and 
architecture merge (Def. 12) and provide a stronger version of the soundness 
theorem (Thm. 17). Moreover, the whole discussion of input equivalence 
(Sect. 2.9.4) is new. Finally, the paper provides detailed examples of all 
concepts and provides proofs for all lemmata and theorems. 


1.2. Running Example: Specifying Blackboard Architectures 


In this paper, we use the Blackboard architecture design pattern as a run- 
ning example to show our approach to the specification and verification of 
dynamic architectures. This pattern was described, for example, by Shaw 
and Garlan [28], Buschmann et al. [9], and Taylor et al. [30]. 

Blackboards work with problems and solutions for them. Hence, we 
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denote by PROB the set of all problems and by SOL the set of all solutions. 
Complex problems consist of subproblems which can be complex themselves. 
To solve a problem, its subproblems have to be solved first. Therefore, we 
assume the existence of a subproblem relation < C PROBxPROB. For complex 
problems, this relation may not be known in advance. Indeed, one of the 
benefits of a Blackboard architecture is that a problem can be solved also 
without knowing this relation in advance. However, the subproblem relation 
has to be well-founded (wf) for a problem to be solvable. In particular, we 
do not allow cycles in the transitive closure of <. 

While there may be different approaches to solve a problem (i.e. several 
ways to split a problem into subproblems), we assume that the final solu- 
tion for a problem is unique. Thus, we assume the existence of a function 
solve: PROB — SOL which assigns the correct solution to each problem. 
Note, however, that this function is not known in advance and it is one of 
the reasons of using this pattern to calculate this function. 


2 A Model of Dynamic Architectures 


In the following we introduce our model of dynamic architectures. It is 
based on Broy’s Focus theory [6] and an adaptation of its dynamic ex- 
tension [7]. A property is modeled as a set of configuration traces which 
are sequences of architecture configurations that, in turn, consist of a set 
of active components, valuation of their ports with type-conform messages, 
and connections between their ports. This model serves the specification of 
properties for dynamic architectures as shown by the running example. 


2.1 Foundations 


This section introduces basic concepts of our model such as ports which can 
be valuated by messages. 


Convention 1 (Functions). Given two sets A and B we denote with A B 
the set of functions with domain A and range B. For a function f: A B 
we denote with dom (f) 4! A the domain of f and with ran (f) 2 


its range. 


Convention 2 (Indexed family of sets). Given a non-empty set I, we denote 
with (Si)ier a family of sets indexed by I, i.e., a mapping associating a set 
S; with each element i € I. 
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2.1.1 Messages and Ports 


In our model, components communicate by exchanging messages over ports. 
Thereby, ports are typed by a set of messages which can pass the correspon- 
ding port. Thus, we assume the existence of the following sets: 
e set M containing all messages, 
e sets P; and P, containing all input and output ports, respectively, and 
set P = P; UP, containing all ports. We require a port to be either 
input or output, but not both: 


P;AP, =9 . (1) 


Moreover, we assume the existence of a type function which assigns a set of 
messages to each port: 


(Tp)pep, with T, C M for each pe P . (2) 


2.1.2 Valuations 


In our model, components communicate by sending and receiving messa- 
ges through ports. This is achieved through the notion of port valuation. 
Roughly speaking, a valuation for a set of ports is an assignment of messa- 
ges to each port. Note that in our model, ports can be valuated by a set of 
messages meaning that a component can send/receive no message, a single 
message, or multiple messages at each point in time. Moreover, ports can 
only handle type-conform messages, i.e., messages belonging to the port’s 
assigned type. 

In the following, we denote with ¢(S') the powerset of S, i.e., the set of 
all subsets of S. For ports P C P, we denote by P the set of all type-conform 
port-valuations (PVs), formally, 

P © {u: P > e(M)|Ype P: p(p) CT} . (3) 
Moreover, we denote by [p1, p2,... > {mi}, {m2},...] the valuation of ports 
P1,p2,--- with sets {mj },{m2},... , respectively. For singleton sets we 
shall sometimes omit the set parentheses and simply write [pi1,p2,... 
ig aT es | 


2.2 Components and Interfaces 


This section introduces the basic notions of component and interface. 
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2.2.1 Components 


In our model, the basic unit of computation is a component. A component is 
identified by a component identifier which is why we postulate the existence 
of the set of all component identifiers C. 


Component port valuation. In our model, the same port can be reused 
by different components. Thus, to uniquely identify a component port, 
we need to combine it with the corresponding component. Therefore, we 
extend the notion of PV introduced in Eq. (3) for component ports (CPRs) 
Pep © C x P to component-port-valuations (CPVs): 


Py © {u: Pop > 9(M)|V(c,p) € Pep: w((c,p)) © Tp} - 


2.2.2 Interfaces 


A component communicates with its environment through an interface by 
sending and receiving messages over ports. 


Definition 3 (Component interface). A component interface (CI) is a pair 
(BPs) te 

e input ports P; CP; , and 

e output ports Ps CP» . 
The set of all CIs is denoted by T. 


Similar to components, interfaces have an identifier which is why we 
postulate the existence of the set of all interface identifiers |. 


Interface port valuation. As for components, the same port can be used 
by different interfaces. Thus, to uniquely identify an interface port, we need 
to combine it with the corresponding interface identifier. Therefore, we can 
extend the notion of PV introduced in Eq. (3) for interface ports (IPRs) 
Pig =| P to interface port valuations (IPVs): 


> def 
Pp = {u: Py > @(M)|V(c,p) © Pip: w((e,p)) S Tp} - 
2.3 Interface Specifications 


An interface specification declares a set of component and interface identi- 
fiers. Moreover, it associates an interface identifier with each component 
identifier and an interface with each interface identifier. 
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Definition 4 (Interface specification). An interface specification (IS) is a 
4-tuple (C,I,t°,t*) consisting of: 
e a set of component identifiers CCC , 
e a set of interface identifiers I C\ , 
e a mapping t°: C > I, assigning an interface identifier to each compo- 
nent, 
e a mapping t': I > Z, which assigns an interface to each interface 
identifier. 
The set of all interface specifications is denoted by Sy. 


Convention 5. For an n-tuple Z = (z1,...,2n), we denote by [z]' = 
with 1 <<i<n the projection to the i-th component of Z. 


Definition 6 (Interface ports). For interface specification S; = 
(C,I,t°,t') € Sy we denote by: 


e in(S;, I’) 2 User {i} x [t*(a)]") the set of interface input ports , 
e out(S;, I’) sie Uier {i} x [*(@)]) the set of interface output 
ports , 
def 


e port(S;, I’) in(S;, I’) Uout(S;, I’) the set of all interface ports , 
for a set of interface identifiers I’ C I, respectively. 


The same notation can be used to denote the ports for a set of compo- 
nent identifiers C’ C C of interface specification $; = (C,I,t°,t’) € Sr; by 
substituting t’(i) with t'(¢°(c)) for each c € C" in the above definitions. 


2.4 Specifying Interfaces 


To specify interfaces, as a first step, a suitable signature is specified to intro- 
duce symbols for sets, functions, and predicates. These symbols form the 
primitive entities of the whole specification process. Datatype specificati- 
ons and interface specifications as well as the specification of architectural 
constraints are based on these symbols. 

Then, datatypes are algebraically [8, 32] specified over the signature. 
A datatype specification (DTS) consists of a set of so-called datatype asser- 
tions, built over datatype terms, to assert characteristic properties of the 
datatype and provide meaning for the symbols introduced in the signature. 

Interfaces are also directly specified over the signature. Therefore, a 
set of ports is typed by sorts of the corresponding signature by means of 
so-called port specifications. Then, an interface is specified by assigning 
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an interface identifier with three sets of ports: local, input, and output 
ports. Finally, a set of interface assertions is associated with each interface 
identifier to specify component types, i.e., interfaces with associated global 
invariants. 


2.5 Running Example: Blackboard Interface Specification 


A Blackboard architecture consists of a BlackBoard component and several 
KnowledgeSource components. Figure 1 and Fig. 2 shows corresponding 
datatype and port specifictaions. Figure 3 then, shows an interface specifi- 
cation Spe = (C,I,t°,t’) € S; of the pattern. 


DTSpec ProbSol imp SET 


sort PROB, SOL PSpec BPort uses ProbSol 
<: PROB x PROB ip: PROB x ¢(PROB) 
poet once Bg CF ye Ky « Mee eeenal§ Ren ag 1s: PROB x SOL 
i eee tia seriio a! Op: PROB 
well-founded(~<) (4) Os: PROB x SOL 
Figure 1: Datatype Specification. Figure 2: Port Specification. 


BlackBoard interface. A BlackBoard (BB) is used to capture the current 
state on the way to a solution of the original problem. Its state consists of 
all currently open subproblems and solutions for subproblems. 

A BlackBoard expects two types of input: 1. via ip: a problem p € 
PROB which a KnowledgeSource is able to solve, together with a set of 
subproblems P C PROB the KnowledgeSource requires to be solved before 
solving the original problem p, 2. via i,: a problem p € PROB solved by a 
KnowledgeSource, together with the corresponding solution s € SOL. 

A BlackBoard returns two types of output: 1. via op: a set P C PROB 
which contains all the problems to be solved, 2. via 0,: a set of pairs PS C 
PROB x SOL. Thus, we require the port types: Tj, = PROB x g(PROB), and 
T;, = PROB x SOL, Top = PROB and 7,, = PROB x SOL. 


KnowledgeSource interface. A KnowledgeSource (KS) is a domain ex- 
pert able to solve problems in that domain. It may lack expertise of other 
domains. Moreover, it can recognize problems which it is able to solve and 
subproblems which have to be solved first by other KnowledgeSources. 


On Activation, Connection, and Behavior in 
Dynamic Architectures 195 


Figure 3: Interface specification for Blackboards. 


A KnowledgeSource expects two types of input: 1. via zp: a set P C 
PROB which contains all the problems to be solved, 2. via ig: a set of pairs 
PS C PROB x SOL containing solutions for already solved problems. 

A KnowledgeSource returns one of two types of output: 1. via op: a 
problem p € PROB which it is able to solve together with a set of subproblems 
P C PROB which it requires to be solved before solving the original problem, 
2. via os: a problem p € PROB which it was able to solve together with the 
corresponding solution s € SOL. Thus, we require the port types: Tj, = PROB 
and T;, = PROB x SOL and ‘ey = PROB x ¢o(PROB) and T,, = PROB x SOL. 

While we assume only one BlackBoard component bb € C’, the number 
of KnowledgeSource components is not restricted. 


2.6 Architecture Configurations and Configuration Traces 


Architectures are modeled as sets of configuration traces which are sequences 
over architecture configurations. 


2.6.1 Architecture Configurations 


In our model, an architecture configuration connects ports of active compo- 
nents. It consists of a set of active components and a so-called connection 
relation connecting the component ports. 


Definition 7 (Architecture configuration). An architecture configuration 
(AC) over IS 9; = (C,I,t°,t’) € Sy is a triple (C’, N, 1), consisting of: 

e a set of active components C' CC , 

e a connection N: in(S;,C’) + g(out(S;,C’)), 

such that V(c,p) € in(S;,C"), (co, Po) € N((c,p)): Tp, © Tp , 

e a valuation  € port(S;,C’) . 
We require connected ports to be consistent in their valuation, i.e. if a com- 
ponent provides messages at its output port, these messages are transferred 
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to the corresponding connected input ports: 


Vpi € in(S;,C’): NO) #0 => wi) = LJ ne) - (5) 
PoE N (pi) 


The set of all possible ACs for interface specification S; € S; is denoted by 
KGS: )s 


Note that connection N is modeled as a set-valued, partial function 
from component input ports to component output ports, meaning that: 
e input/output ports can be connected to several output/input ports, 
respectively, and 
e not every input/output port needs to be connected to an output/input 
port, respectively. 


Convention 8. In the following we use c :: I to denote that component 
variable c requires any assigned component to have interface I. Moreover, 
port names are used to denote the corresponding port valuation. 


Example 1 (Architecture configuration). Let pi, p2, ps, (p1, $1), (p2, $2) € 
M, ksz, ksg, bb € C, tp, ts € Pi, and Op, 0s € Po. Figure - shows an 
AC (C',N,) for interface specification Sgp (as defined in Sect. 2.5 with 
C = {ks1, ksg, bb}), with: 
e active components C’ = {ks1, bb}; 
e connection N, with N((bb, op)) = {(K81, tp)}, N((bb, os)) = {(ks1,%s)}, 
N((k81, Op)) = {(0b, ip) }, N((ks1,0s)) = {(bb,ts)}; and 
e valuation b= 
[(k51,%p),(K81, 0p), (bb, Os),---++ {p1,p2,P3}, { (pa, {pat} ((p1, $1) f°]: 


Ports of an architecture configuration can be classified as either open 
or connected, depending on whether they are connected to any other ports 
or not. Ports which are not connected to any other port are called open 
configuration ports. 


Definition 9 (Open configuration port). For an ACk = (C’, N, 1) € K(S;) 


over IS’ S; we denote by: 


e ing(S;, k) = {p € in(S;,C’) | N(p) = 0}, the set of open input 


ports, 


For sake of simplicity, the configuration diagrams used in this paper only show active 
components of a configuration. 
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bb.0p = ks1.ip = {p1, 2, ps} 
bb.05 = ks1.45 = {(pi, 51)} 
bb.ip = ks1.0p = {(p2, {pa})} 
bb.i, = k81.05 => {(pa, 82)} 


Figure 4: Architecture configuration 


© out,(S;,k) “  {p € out(S,,C") | Ap’ € in(5;,C’): p € N(p)}, the 
set of open output ports, 
e port,(S;, k) = ing (Si, &) U out,(S;,k), the set of all open ports. 
On the other hand, ports which are connected to other ports are called 
connected configuration ports. 


Definition 10 (Connected configuration port). For an ACk = (C", N, ) € 
K(S;) over IS S; we denote by: 


e in(S;, k) aah {p € in(S;,C’) | N(p) # O}, the set of connected 
input ports, 


e out.(S;,k) “ {6 © out(S;,C") | 3p! € in(S;,C"): p € N(p)}, the 
set of connected output ports, 
e port.(S;, k) ae ine(S;,k) U out.(S;,kh), the set of all connected 


ports. 


2.7 Running Example: Architecture Configurations 


In a Blackboard architecture, a KnowledgeSource can solve only certain 
types of problems which is why we assume the existence of a mapping 
prob: C' + PROB to associate a set of problems with each KnowledgeSource. 
Then we require for each KnowledgeSource that it only solves problems 
given by this mapping: 


Vk € K(Spp), (c,p) € out(S;,k): t°(c) = KS —> [[k]°(p)] € prod(c) - 
6 
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2.8 Architecture Merge 


It is possible to create a new architecture configuration from existing ar- 
chitecture configurations by merging activation, connection, and behavioral 
aspects. 

In order to be mergeable, architecture configurations have to fulfill 
certain conditions. 


Definition 11 (Mergeable architecture configurations). ACs ky = 
(C!,, Na, Ma), kn = (Ch, Nn; bn), and ky = (Ch, No, ty) over interface specifi- 
cation S; € Sy; are called mergeable, denoted \(ka, kn, ky), iff the following 
conditions hold: 

e Components are consistent in their valuation of input ports: 


Ve € in(S;,CL A CLAC): 
(6 € in(S;,C",) V Ha(p) = 0) A 
(6 € in(S;,C,) V Un(p) = 9) A (7) 
(p € in(S;, C4) V uy(b) = B) 
V fa(P) = Un(D) = Mo(P) - 


e Types and valuations of newly connected output ports are consistent 
with the corresponding types and valuations of connected input ports 
for all components: 


Vpi € {p € in(S;,C,. C2) | Nn(p) N out(S;,C)) AO}: 
Ma(Bi) = Un(Bi) = Ho(Pi) = U Le(Bo) - 


PoE Nn (pi )Mout(S;,Cf )Nout(S;,C;) 
(8) 


e AC k, (responsible for activation), is not allowed to influence con- 
nection aspects: 


V(c,p) € in(S;,C;,),(¢,p') € Nn((ep))se ECQAT ECA. — (9) 
e Moreover, AC kg is not allowed to influence behavioral aspects: 
V(c,p) € out(S;,Ch): ws((c,p)) #0 =} cEeCc. (10) 


A necessary condition for architecture configurations to be mergeable 
is that they are consistent in their valuation of input ports as required by 
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Eq. (7). However, this is not a sufficient condition since an architecture 
merge may have newly created connected output ports, i.e., ports which are 
not connected in any of the original architecture configurations. Since they 
are to be connected in the corresponding merge, they have to be consistent 
in their valuation of these ports in order to satisfy Eq. (5) of Def. 7. This 
is what Eq. (8) requires. Finally, AC ka, specifying the activation of the 
merge, is not allowed to influence neither connection nor behavior. Thus, 
connected components in the second AC have to be activated in the first 
one (9) and so has every component which has any valuations for output 
ports (10). In the following we provide an example of three ACs violating 
these requirements. 


Example 2 (Non-mergeable architecture configurations). Figure 5 depicts 
three AC's which are not mergeable. Indeed, the three ACs violate several of 
the requirements provided in Def. 11. 

e First, the ACs differ in their valuation of input ports (thus, violating 
Eq. (7)): While AC 5a has {p2, ps} on its input port (bb, ip), the same 
port is valuated with {p2,{pa}} in AC 5b and with {pi,p2} in AC Sc. 

e Moreover, since AC’ 5a lacks component ks;, it does not allow for 
a merge which has connections as required from AC 5b (thus, viola- 
ting Eg. (9)) or a behavior as required from AC 5c (thus, violating 
Eq. (10)). 

e Finally, there is an inconsistency between AC 5b and AC 5c (thus, 
violating Eq. (8)): Since port (ks1,is) is connected to port (bb,os) in 
AC 5b, the corresponding merge is required to have the same valuation 
of these two ports (cf. Def. 7). However, port (bb,os) is valuated 
by a {(p3,84)} in AC 5c and the corresponding input port (ksz,7s) 
with a {(p3,2)}. Thus, the corresponding merge would result in an 
inconsistent AC. 


Example 3 (Mergeable architecture configurations). Figure 6 depicts three 
ACs which are indeed mergeable®. The ACs satisfy all conditions required 
by Def. 11: 

e First, note that they all have the same valuation of input ports. Note 
that AC 6c has one component in addition to AC 6a. However, their 
input ports are all valuated by the empty set, thus, still satisfying 
Def. 11. 


3Green indicates the parts of an AC which are indeed allowed to differ. 
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{(p1, 81) } {(p2, 82)} 
{pi, p2,p3} : {p2, ps} x 


pa \ ! / 


S 
@—e—~ C 
Op Os tp ts 


(a) First architecture configuration. 


~~ {pi, p2} 


< {pi, p2} 


7 _--> {(p2, 82)} 


(c) Third architecture configuration. 


Figure 5: Non-mergeable architecture configurations. 


e Note that AC 6b requires output port (bb,0,) to be connected to input 
port (ks1,ip) and output port (ks;,0s) to be connected to input port 
(bb,is). Since (bb, 0p) is valuated with {(p1,p2,p3)} and (ks;,0s) with 
{(p2,52)} in AC 6c, all three ACs are required to be valuated with 
{(p1, p2,p3)} on input port (ks1,%)) and with {(p2, s2)} on input port 


(bb, is). 


e Finally, since AC 6c introduces a new component ksg which is not 
active in AC 6a, each corresponding output port must be valuated by 


the empty set. 
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{p1, paps} <7 72 77? tee, {pat} 


{(pi,s1)} - 


\ 
\ 
\ 


{(ps, $2)} ~--__\, 


“7 >= = {po, {pa}} 


\ 
\ 


es {p2, {pat} 
_--> {(p2, s2)} 


{pi,pa,ps}-" 67 7 oe 2. SS 0 

{(pi,si)} <7 27 2" {(p1,81)}— {p2, {pa}} SS SSO 
By : ; or 

{p2, {pat} -° {pi p2,pa} [A (p2;82)} ss 0 


{(p2,82)} ~~ sO 


(c) Third architecture configuration. 


Figure 6: Mergeable architecture configurations. 


Lemma 1 (Reflexivity of mergeable). For every AC k = (C’, N,), over 
interface specification S; € S;, k is mergeable with itself: \(k, k, k). 


The proof is given in App. A.1. 
Having a definition of mergeable architecture configurations allows to 


define the notion of architecture merge. 
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Definition 12 (Architecture merge). Given ACs ka = (C",,.Na; Ma); kn = 
(Cl, Nn, in), and ky = (Ch, Np, uy) over interface specification S; € S;, such 
that Y (ka, kn, ky), we define their architecture merge as the AC Y (ka, kn, ky) = 
(C’, N, 1) with C’ = Cl, N: in(S;,C’) > p(out(S;,C’)), such that 

0 ifc€ Ci, 
N((c,p)) = or i eyo Ss ae 

{(¢,p') € Nn((e,p)) | CEC} ifeec, 
TAG) if p € out(S;, C5) 

if p € out(S;, C") \ out(S;, CZ) 

Usenp) L(Do) if p € ine (Si, Yk: Ris ky) ) 
Ha(D) if p € ing(Si, V (Ee kas ky)) 


The architecture merge allows to create a new architecture configura- 
tion by merging the different aspects of existing architecture configurations. 
Thereby, a merge of three architecture configurations is a new architecture 
configuration with the activation of the first architecture configuration, the 
connection of the second architecture configuration, and the behavior of the 
last architecture configuration. 


and jt € port(.S;, C’), 


such that u(p) = 


Example 4 (Architecture merge). Figure 7 depicts the merge of the ACs 
depicted in Fig. 6. The resulting AC has the same active components as 


Figure 7: Merge of architecture configurations from Fig. 6. 


AC 6a, the same connection as AC 6b, and the same valuation of output 
ports as AC’ 6c. Moreover, its valuation of input ports is given by the valua- 
tion of input ports of each of the original architecture configurations (which 
is guaranteed to be the same for each AC due to Def. 11). 


Proposition 1 (Well-definedness of architecture merge). For all ACs kg = 
(C1, Nasa), kn = (Ci, Nn, bn), and ky = (Ci, No, uy) over interface speci- 
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fication S; € Sy, their architecture merge ¥ Balke ky) is a unique AC in 
KGS): 


Sketch of the proof (Full proof is given in App. A.2): We show existence 
and uniqueness of Ve Kins ky). 

Existence: Let Y(ka, kn, kp) = (C’, N, 1) be defined as in Def. 12. By 
Def. 7 we have to show: C’ C C, N: in(S;,C’) > g(out(S;,C0")), uw € 
port(S;,C’), and Vp; € in(S;,C’): N(pi) # = [A(Di) = Ussen(p;) Ho) 
to conclude Y¥ (has ng ky) € K(S;). 

Uniqueness: Let k’ = (C”, N’, uy’) be defined as in Def. 12 and show 
C" =C', N'=N, and p! = p to conclude k! = Y (ka, kn, ky). 


Lemma 2 (Merge identity). For every AC ka = (C",, Na, fa), over interface 
specification S; € S;, the architecture merge of kg results in kg itself: kg = 


Y (ka; ka; ka): 


A full proof of this lemma is given in App. A.3. 


2.9 Relations Between Architecture Configurations 


Architecture configurations can be related according to several aspects. 


2.9.1 Activation Equivalence 


One aspect which can be used to relate architecture configurations is their 
active components. 


Definition 13 (Activation equivalence). Two ACs k = (C’,N,p), k’ = 
(C”",N’, uw’) over interface specification S; € S;, with k,k’ € K(S;), are 
activation equivalent, written k ~*% k’, iff 


C=C", (11) 


In the following we provide an example of two activation-equivalent 
architecture configurations. 


Example 5 (Activation-equivalent architecture configurations). Fig. 8 de- 
picts two activation-equivalent AC's. They both have active components ks 
and bb. Note that they differ in their valuation of ports (ks1;,0p)) and (bb, ip). 
Moreover, they differ in their connection since in one of them (ks1,0p) is 
connected to (bb, ip) while in the other these ports are unconnected. 
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Figure 8: Two activation-equivalent architecture configurations. 


We also provide an example of two architecture configurations which 
are not activation equivalent. 


Example 6 (Non-activation-equivalent architecture configurations). Fig. 9 
depicts two ACs which are not considered to be activation equivalent. While 


{(p1, 51) } {(p2, 82) } 


\ 7 


/ 


\ 
£ 


a {p2,{pa}} eres \ ipa teed} ra 


Figure 9: Two non-activation-equivalent architecture configurations. 


component ks; is active in one of the ACs, it is deactivated in the other. 
Note that they are equal, however, in all their port-valuations. 


Note that activation equivalence is indeed an equivalence relation. 


Lemma 3 (Activation equivalence). Activation equivalence is an equiva- 
lence relation. 


Sketch of the proof (Full proof is given in App. A.4): _ It is reflexive, 
symmetric, and transitive. 

Finally, an architecture merge is always activation equivalent to its first 
architecture configuration. 
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Lemma 4 (Activation equivalence of merge). For all ACs ka = (C’,, Na; Ma); 
kn = (Ci,,Nn bn), and ky = (Ch, No, uy) over interface specification S; € 
S; we have that their merge Y (ka; kn, ke) is activation equivalent to kg: 
¥ Chas Kn, ky) a ka- 


A full proof of this lemma is given in App. A.5. 


2.9.2 Connection Equivalence 


Another aspect according to which architecture configurations can be rela- 
ted is their connections. 


Definition 14 (Connection equivalence). Two ACs k = (C’, N, pw) and k! = 
(C”",N’,u’) over interface specification S; € S; are connection equivalent, 
written k =” k’, iff 


Vp; € in(S;,C'N Crys N(pi) = N'( d;) A 
Vpi € ins VO 2 N( ;) =O A 
Voi € in(S;,C" \ C’): N'(p;) =O . 


Note that the deactivation of components is interpreted as if all their 
ports are not connected to any other port. Thus, if an architecture con- 
figuration & has a component activated which is not activated in another 
architecture configuration k’, all the ports of this component have to be 
unconnected in k, in order for k to be (possibly) connection equivalent to 
kK. 

In the following we provide an example of two connection-equivalent 
architecture configurations. 


Example 7 (Connection-equivalent architecture configurations). Fig. 10 
depicts two connection-equivalent AC's. Note that they do have two input 
ports in common: ty andis of component bb and that their connection agrees 
on these input ports, t.e., they are unconnected in both ACs. Moreover, tp 
and is of component ks; are only available in the first AC. Thus, Def. 14 
requires them to be unconnected. 

Note also that both ACs differ in their active components (ks, is only 
active in one of the two) and in their valuation of ports, e.g., (bb,0;) and 


(bb, is). 


We also provide an example of two architecture configurations which 
are not connection equivalent. 
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{(p1, $1), (p3, 82) } {(p1, 83) } 
{pip er S 9 ~{(p1, 84) } {p1,P2,P3} {p2, {pa}} v 
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{p1,p2,p3}~ --@ > <= - -{(p2, 52)} 


Figure 10: Two connection-equivalent architecture configurations. 


Example 8 (Non-connection-equivalent architecture configurations). Fig. 11 
depicts two ACs which are not considered to be connection equivalent. Alt- 


Figure 11: Two non-connection-equivalent architecture configurations. 


hough both ACs have ks; and bb activated, in one of the ACs, port (ks1,%s) 
is connected to port (bb,0;,) while in the other one, these two ports are un- 
connected. Note, however, that they are equal in their components as well 
as their valuation of ports. 


In the following we provide an important property of connection equi- 
valence. 


Lemma 5 (Connection equivalence). Connection equivalence is an equiva- 
lence relation. 


Sketch of the proof (Full proof is given in App. A.6): — It is reflexive, 
symmetric, and transitive. 

An important property of an architecture merge is that it is always 
connection equivalent to its second architecture configuration. 
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Lemma 6 (Connection equivalence of merge). For all ACs kg = (C!,, Na; Ma); 
kn = (Ci,,Nn; bn), and ky = (Ch, No, ly) over interface specification S; € 

S; we have that their merge Vi kaoln, ie) is connection equivalent to ky: 
¥ Cees kn, ky) i kn. 


A full proof of this lemma is provided in App. A.7. 


2.9.3 Behavior Equivalence 


Architecture configurations can also be related according to their behavior, 
i.e., the valuation of their output ports. 


Definition 15 (Behavior equivalence). Two ACs k = (C’,N,) and k! = 
(C”,N',u') over interface specification S; € Sr are behavior equivalent, 
written k x k’, iff 


Vp € out(S;,C’ NC”): p( [ 
Vp € out($;,C’ \ C”): u(p) =0 A 
/ 
0 


Similar to connection equivalence, the deactivation of components is 
interpreted as if all their output ports are valuated by the empty set. Thus, 
if an architecture configuration k has a component activated which is not 
activated in another architecture configuration k’, all the output ports of 
this component have to be valuated by the empty set in k, in order for k to 
be (possibly) behavior equivalent to k’. 

In the following we provide an example of two behavior equivalent 
architecture configurations. 


Example 9 (Equivalent architecture configurations). Fig. 12 depicts two 
behavior equivalent AC's. Note that they do indeed differ in their active 
components as well as their valuation of input ports. However, as required 
by Def. 15, they do have the same valuation of their common output ports 
(bb, op) and (bb, 0s). Moreover, all output ports which exist only in the first 
AC (0p and og of component ks;) are valuated by the empty set. 


We also provide an example of two architecture configurations which 
are not behavior equivalent. 


Example 10 (Non-equivalent architecture configurations). Fig. 13 depicts 
two ACs which are not considered to be behavior equivalent. Although both 
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Figure 12: Two behavior equivalent architecture configurations. 


f- 


{p2, {pa}} {p2, {pa}} 


{(p2, 52) } {(p2, 82) } 


Figure 13: Two non behavior equivalent architecture configurations. 


ACs have the same components activated and the same connections between 
their ports, in one of the ACs, port (bb, op) is valuated with {p1, p2,p3}, while 
in the other AC the same port is valuated with {po}. 


Also behavior equivalence is indeed an equivalence relation. 


Lemma 7 (Behavior equivalence). Behavior equivalence is an equivalence 
relation. 


The proof for this lemma is similar to the proof of Lem. 5. 
An important property of an architecture merge is that it is always 
behavior equivalent to its third architecture configuration. 


Lemma 8 (Behavior equivalence of merge). For all ACs kg = (C",, Na, La); 

kn = (Cl, Nn, Un), and ky = (Ch, No, wy) over interface specification S; € Sy 

we have that their merge V (ha: kn, kp) is behavior equivalent to kp: has Kis kp) we? 
kp. 


A full proof of this lemma is provided in App. A.8. 
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2.9.4 Input Equivalence 


Finally, architecture configurations can be related according to their valua- 
tion of input ports. Note that we separate input equivalence from behavior 
(output) equivalence here. The reason is, that all the aspects of dynamic ar- 
chitectures (including behavior) are usually specified based on the valuation 
of input ports. 


Definition 16 (Input equivalence). Two ACs k = (C’, N, 1), k! = (C”, N’, py’) 
over interface specification S$; € S;, with k,k’ € K(S;), are input equivalent, 
written k = k’, iff 


Again, the deactivation of components is interpreted as if all their input 
ports are valuated by the empty set. Thus, if an architecture configuration 
k has a component activated which is not activated in another architecture 
configuration k’, all the input ports of this component have to be uncon- 
nected in k, in order for k to be (possibly) input equivalent to k’. 

In the following we provide an example of two input equivalent archi- 
tecture configurations. 


Example 11 (Equivalent architecture configurations). Fig. 14 depicts two 
input equivalent ACs. Note that they do indeed differ in their active com- 


Figure 14: Two input-equivalent architecture configurations. 


ponents as well as their valuation of output ports. However, as required 
by Def. 16, they do have the same valuation of their common input ports 
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(bb, ip) and (bb,is). Moreover, all input ports which exists only in the first 
AC (ip and is of component ks1) are valuated by the empty set. 


We also provide an example of two architecture configurations which 
are not input equivalent. 


Example 12 (Non-equivalent architecture configurations). Fig. 15 depicts 
two ACs which are not considered to be input equivalent. Although both AC's 


Bic {p2, {pa}} 


7 


\ 


Vv 
/ 


Figure 15: Two non-input-equivalent architecture configurations. 


have the same components activated and the same connections between their 
ports, in one of the ACs, port (ks1,is) is valuated with {(p1,s1)}, while in 
the other AC the same port is valuated with {(p3, 55)}. 


Also input equivalence is indeed an equivalence relation. 
Lemma 9 (Input equivalence). Input equivalence is an equivalence relation. 


Sketch of the proof (Full proof is given in App. A.9): Proof is similar 
to the one for Lem. 7. 

A property of mergeable architecture configurations is that they are 
indeed input equivalent to each other. 


Lemma 10 (Input equivalence of mergeable). For all ACs ka, kn, ky € 
K(S;), such that Y(ka, kn, ky), we have kg &* kn, kq & ky, and kn & kp. 


A full proof of this lemma is provided in App. A.10. 
An important property of an architecture merge is that it is always 
input equivalent to all its architecture configurations. 
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Lemma 11 (Input equivalence of merge). For all ACs ka, kn, ky € K(Si), 
such that Y(ka, kn, kp), each AC is input equivalent to their merge V has kn, ky) : 


Ka ae Y (Ka; kn ko) ’ 
kn = (Ka, kn, ko) , and 
Ree keg, ahs) 4 


Sketch of the proof (Full proof is given in App. A.11): kg =* (Ras kin, a 
For open input ports equality follows from Def. 12. Equality of connected 
input ports follows from Def. 11. kp, =* Chas kn, ky) and ky, =" Vas Keres ky) 
follows from Lem. 10 and transitivity of ~' (Lem. 9). 


2.9.5 Relating Activation, Connection, Behavior, and Input 


The relations introduced so far suffice to determine architecture configura- 
tion equivalence. 


Lemma 12 (Equality of architecture configurations). Two ACs k,k’ € 
K(S;) are the same iff they are activation equivalent, connection equivalent, 
behavior equivalent, and input equivalent: 


k=K = RAR ARR ARE KARE . 


The proof of this lemma is given in App. A.12. 

Note, that the right hand side of the equation in Lem. 12 is not the 
weakest one to determine equality of architecture configurations. Indeed, 
it would be sufficient to require that k and k’ have the same valuation of 
their open input ports. The equality of connected input ports follows then 
from k x k! and k =” k’ since Def. 7 requires connected input ports to be 
valuated by the union of the valuation of the corresponding output ports. 
Nevertheless, the above equality is sufficient for the following explanations. 


Open input equivalence. The above observation would actually provide 
evidence to introduce a weaker notion of input equivalence in which we only 
required open input ports to be equivalent in order for two architecture 
configurations to be considered input equivalent. As it turns out, however, 
this is not sufficient to achieve transitivity which is an important property 
required for the remaining discussion. 
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(a) First AC. (b) Second AC. (c) Third AC. 


Figure 16: Three architecture configurations. 


Example 13 (Why equivalence of open input ports is not transitive). Con- 
sider the three AC's depicted in Fig. 16. Since AC 16a and AC 16b have 
no common open input ports, they have vacuously the same valuation of 
their common open input ports. Similar for AC 16b and AC 16c. However, 
AC 16a and AC 16c share two open input ports iy and is and they differ in 
the valuation of one of them. 

Therefore, if input equivalence would only consider valuations of open 
input ports, AC’ 16a and AC 16b would be considered input equivalent and 
so would be AC 16b and AC 16c. However, AC 16a and AC 16c would not 
be considered input equivalent which is why this notion of input equivalence 
would not be transitive and, thus, not an equivalence relation at all. 


Strong equivalence of open input ports. We could even try to further 
strengthen the notion of equivalence of open input ports to consider all input 
ports which are open in at least one of the two architecture configurations. 
Although this is now a stronger version as the one discussed in Ex. 13 
(indeed architecture configuration 16a and architecture configuration 16b or 
architecture configuration 16b and architecture configuration 16c would not 
be considered input equivalent anymore), it is still weaker than our working 
definition of input equivalence provided by Def. 16. 

However, as shown in the following example, also this notion of input 
equivalence is not transitive. 


Example 14 (Why strong equivalence of open input ports is not transitive). 
Consider the three AC's depicted in Fig. 17. Since ports ip and is of com- 
ponent bb are open input ports in AC 16a, they need to be considered when 
relating another AC to AC 16a. However, since the valuation of these two 
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(a) First AC. (b) Second AC. (c) Third AC. 


Figure 17: Three architecture configurations. 


ports is the same for AC 16a and AC 16b, they would be considered input 
equivalent. AC’ 16b and AC 16c have no open input ports, at all. Therefore, 
also these two would be considered input equivalent. However, AC 16c varies 
in its valuation of input port (bb, i») from AC 16a which is why AC 16a and 
AC 16c would not be considered input equivalent. 

Thus, if input equivalence would also consider valuations of input ports 
which are open in one of the ACs, AC 16a and AC 16b would be considered 
input equivalent and so would be AC 16b and AC 16c. However AC 16a 
and AC 16c would not be considered input equivalent which is why also 
this notion of input equivalence would not be transitive and thus not an 
equivalence relation, at all. 


Thus, although Def. 16 is not the weakest definition of input equivalence 
which leads to Lem. 12, it is the only one which is transitive. 


2.10 Configuration Traces 


A configuration trace consists of a series of configuration snapshots of an ar- 
chitecture during system execution. Thus, a configuration trace is modeled 
as a sequence of architecture configurations at a certain point in time. 


Definition 17 (Configuration trace). A configuration trace (CT) over in- 
terface specification S; € Sy; is a mapping N > K(S;). The set of all CTs 
for S; is denoted by K'(S;). 


Example 15 (Configuration trace). Figure 18 shows a CT t € K*(S;) with 
corresponding ACs t(0) = ko, t(1) = ky, and t(2) = kp. AC ko, for example, 
is shown in Example 1. 
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Figure 18: Configuration trace (port valuations not shown, see Fig. 4 for an 
example) 


Note that an architecture property is modeled as a set of configuration 
traces, rather than just one single trace. This is due to the fact that compo- 
nent behavior, as well as the appearance and disappearance of components, 
and the reconfiguration of the architecture is usually non-deterministic and 
dependent on the current input provided to an architecture. 

Moreover, note that our notion of architecture is highly dynamic in the 
following sense: 

e components may appear and disappear over time and 
e connections may change over time. 

We can lift the corresponding definitions for architecture configurations 

to configuration traces. 


Definition 18 (Equivalences and mergeable for configuration traces). Gi- 
ven two CTs t,t! € K*(S;) over interface specification S; we have 
d 
tart £4 yn EN: t(n 
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Given other architecture traces t,t!” € K*(S;) we have 
Yet") > WneEN: Y (t'(n),t%(n),t(n)) 


and 
y(tt".t”) 2 aneN: Y(t(n),t"(n), tn) . 
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2.11 Specifying Configuration Traces 


Configuration traces can be specified by means of configuration trace asser- 
tions formulated over interface specifications. Configuration diagrams are a 
graphical extension which allow to graphically express certain configuration 
trace assertions by annotating a given interface specification. 

In the following, we provide a brief, informal description of these techni- 
ques. A more detailed discussion including a presentation of the formal 
semantics of these techniques is provided in [21]. 


2.11.1 Configuration Trace Assertions 


Configuration trace assertions (CTAs) are a temporal specification techni- 
que based on linear temporal logic [20] to specify sets of CTs. They are 
based on the notion of configuration assertions (CNFAs) which allow for 
the specification of a components state. Roughly speaking, CNFAs are for- 
muleespecified over a components interface. Thereby, port names denote 
the valuation of the corresponding component port within an architecture 
configuration and can be used as variables in algebraic terms as well. For ex- 
ample, c.p denotes the current valuation of port p of component c. Moreover, 
CNFAs allow for the specification of activation and connection predicates: 
e Activation predicates can be used to specify activation and deactiva- 
tion of components. An activation of component c, for example, is 
denoted with ||c||. 
e Connection predicates can be used to specify connection between com- 
ponent ports. A connection between port p of component c and port 
p’ of component c’, for example, is denoted with c.p > c’.p’. 
CTAs are then build over CNFAs. Thus, a CNFA is itself a CTA. Moreover, 
if @ and w are CTAs, then O¢, 0¢, Od, and @ W w are CTAs with the 


following meaning: 


e O¢ holds iff ¢ holds of at least one configuration in ¢, 


e O¢ holds iff @ holds of all configurations in ¢, 


e ©¢ holds iff @ holds of the following configuration in ¢, 


e dW w holds iff ¢ holds of all configurations before ~ holds or iff O¢. 
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2.12 Configuration Diagrams 


A configuration diagram (CD) is a graph whose nodes resemble interfaces 
(group of ports) and whose edges denote connections between component 
ports. CDs can be annotated by certain activation and connection con- 
straints: 

e Activation annotations can be used to introduce common activation 
constraints, such as min./max. number of components of a certain 
type. 

e Connection annotations can be used to denote connection constraints, 
such as required connections between components of a certain type. 


3 Specifying Properties of Dynamic Architectures 


Properties of dynamic architectures can be specified as sets of configuration 
traces over an interface specification. In the following, we investigate the na- 
ture of such properties and introduce the notion of behavior, activation, and 
connection properties. We then show that the intersection of such proper- 
ties is guaranteed to contain all necessary configuration traces. Moreover, 
we introduce the notion of separable architecture property and show that 
such a property can always be uniquely represented as the intersection of 
corresponding behavior, activation, and connection properties. 

This way, we get a step-wise method for the specification of properties 
for dynamic architectures by concentrating on the three different property- 
types as shown below by our running example. 


3.1 Activation Properties 


An set of CTs is an activation property if it does neither restrict behavior 
nor connection. 


Definition 19 (Activation property). An activation property (AP) for in- 
terface specification S; € Sy is a set of CTs AC K'(S;), such that connecti- 
ons and behavior are not restricted: 
Vta € A, tn, ty € K'(S;): Y (ta, tn, to) 
SS FCAT SAAS ht, SS BAS Vv tsts) 


Thus, activation properties are defined by means of a special closure 
property for a set of configuration traces A. It requires that for each confi- 
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Diagram Blackboard 
based on BPort uses ProbSol 


prob : o(PROB) 


Ss 
© prob 


P (PROB) 


rp = (p,P) => pe prob (1) 


Figure 19: Configuration diagram for Blackboard. 


guration trace in A, there exists an activation-equivalent configuration trace 
in A for every possible connection and behavior. 


3.1.1 Running Example: Activation Property Specification. 


Activation properties of the Blackboard pattern are described in the con- 
figuration diagram [21] in Fig. 19: The “[1]” annotation for blackboard in- 
terfaces (e.g. BB) denotes the condition that components have to be active 
from the beginning on whereas knowledge source interfaces (e.g. KS) allow 
corresponding components to be de-/activated over time. 

Moreover, we require two additional properties specified in terms of 
CTAs [21], a temporal-logic notation (based on [20]) to specify sets of con- 
figuration traces. 

Figure 20 shows the corresponding specification. We require that ar- 
chitectures are fair w.r.t. knowledge source activation, i.e., each knowledge 
source is activated infinitely many times (Eq. 12). Furthermore, we require 
that whenever a knowledge source offers to solve some problem, it is always 
activated when solutions to the required subproblems are provided (Eq. 13). 

Note that the activation constraints induced by the diagram in Fig. 19 
as well as the additional constraints specified in Fig. 20 constrain only the 
activation of components. They do neither restrict connections nor behavior 
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Spec Blackboard_ Activation uses Blackboard 
var bb: BB 
ks KS 
Pp, PROB 
P PROB SET 
(IlAs|| = O(OllésIl)) (12) 
V(p, P) € ks.op: Vq € P: ((4, solve(q)) € bb.o, > |ksI|) (13) 


Figure 20: Specification of activation constraints for Blackboard architectu- 
res. 


which is why the resulting architecture property is indeed an example of an 
activation property as defined in Def. 19. 
3.2 Connection Properties 


A connection property is not allowed to restrict either behavior or activation. 


Definition 20 (Connection property). A connection property (CP) for 
interface specification S; € S; is a set of CTs N C K'(S;), such that activa- 
tions and behavior are not restricted: 


Vin € N, ta, tp € (Si): Y (ta, tn; to) 
= i ENS GAT See, BAL, = V Gaitaite) 


Thus, connection properties are defined similar to activation proper- 
ties, by means of a special closure property for a set of configuration tra- 
ces N. It requires that for each configuration trace in N, there exists a 
connection-equivalent configuration trace in A for every possible activation 
and behavior. 


3.2.1 Running Example: Connection Property Specification 


Connection properties are also specified graphically in the configuration dia- 
gram in Fig. 19. The solid arcs denote a constraint requiring that the ports 
of a KnowledgeSource component are connected with the corresponding 
ports of a BlackBoard component as depicted, whenever both components 
are active. 
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Figure 21: Example of an ill-formed behavioral property. 


Note that the connection constraints induced by the diagram in Fig. 19 
constrain only the connection of components. They do neither restrict acti- 
vation nor behavior. Thus, the resulting architecture property is indeed an 
example of a connection property as defined in Def. 20. 


3.3 Behavior Properties 


A behavioral property is an architecture property which does not constrain 
connections and activations. 


Definition 21 (Behavior property). A behavioral property (BP) for an 
interface specification S; = (C,I,t°,t’) € S; is a set of CTs B C K*(S;), 
such that connections and activations are not restricted: 
Vtp € B, ta, tn € K'(S;): Y (ta; tn; te) 
SF CBS Nt NS AS Vesta) ¢ 


Again, behavioral properties are defined by means of a special closure 
property for a set of configuration traces B. It requires that for each confi- 
guration trace in B, there exists a behavior-equivalent configuration trace 
in B for every possible activation and connection. 


Example 16 (Not a behavior property). Figure 21 shows how an archi- 
tecture property B can violate Def. 21: Assume that B allows a CT ty 
with ty(0) and denies some traces with k with k ~° t,(0) at n = 0, i.e. 
Ht, € B: t,(0) x? kVU(0) &" k. Hence, B constrains activation and, thus, 
wrongly contains parts of an AP. 


3.3.1 Running Example: Behavior Property Specification 


We provide behavioral properties for both, BlackBoard and KnowledgeSource 
components. Again, we specify the properties in terms of CTAs. Thereby, 
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variables denote component identifiers, problems and solutions. Port na- 
mes are used to denote port valuations and c :: I is used to denote that 
component identifier c has interface I. 


BlackBoard behavior. A BlackBoard provides the current state towards 
solving the original problem. If a KnowledgeSource requires subpro- 
blems to be solved, the BlackBoard redirects those problems to other 
KnowledgeSources. Moreover, the BlackBoard provides available solutions 
to all KnowledgeSources. 

The specification for BlackBoard components is given in Fig. 22. We 


var bb: BB 
p, pl: PROB 
: PROB SET 
s: SOL 
(p,8) € bb.ig => O((p,5) € bb.0,)) (14) 
(p, P) € bb.in —> (Vp' EP: (Op'e bb.0p))) (15) 
Dp € bb.op => (p € bb.op W (p, solve(p)) € bbs) (16) 


Figure 22: Specification of behavior for blackboard components. 


require three properties for them: 

Eq. (14): If a solution to a subproblem is received on its input, then it is 
eventually provided at its output. 

Eq. (15): If solving a problem requires a set of subproblems to be solved 
first, those problems are eventually provided at its output. 

Eq. (16): A problem is provided as long as it is not solved. 


KnowledgeSource behavior. A KnowledgeSource receives open problems 
via 7) and solutions for other problems via 7,. It might contribute to the 
solution of the original problem by solving subproblems. Hence, it per- 
forms one of two possible actions: 1. If it has solutions for all the required 
subproblems, it solves the problem and publishes the solution via o., 2. If 
it requires solutions to subproblems, it notifies the BlackBoard about its 
ability to solve the problem and about these subproblems via op. 

The specification for KnowledgeSource components is given in Fig. 23. 
Also for them we require three properties: 
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Spec Knowledgesource_ Behavior uses Blackboard 
var ks : KS 

P|: PROB 

Poe PROB SET 

V(p,P)Eks.0p: ((VgEP: (q,solve(q)) €ks.is)=>©(p,solve(p))Eks.0s) ) (17) 

V(p, P) € ks.op: Vqge P:q~<p (18) 

péks.probA\p€ ksip = > O(4P: (p,P)€ ks.0p)) (19) 


Figure 23: Specification of behavior for knowledgesource components. 


Eq. (17): If a KnowledgeSource gets correct solutions for all the required 
subproblems, then it solves the problem eventually. 

Eq. (18): In order to solve a problem, a KnowledgeSource requires soluti- 
ons only for smaller problems: 

Eq. (19): If a KnowledgeSource is able to solve a problem it will eventually 
communicate this: 

Note that Eq. (14)-(19) constrain only the behavior of components. 
They do neither restrict activation nor connections. Thus, the resulting ar- 
chitecture property is indeed an example of a behavioral property as defined 
in Def. 21. 


3.4  Soundness of Property Characterization 


In the following, we show soundness of our characterization. Therefore, 
we show that the intersection of an activation, connection, and behavioral 
property contains all necessary configuration traces (and not more). 

First, however, we provide an important property necessary to prove 
the soundness theorem. It states that for every three configuration traces, 
there exists a unique configuration trace which is activation, connection, 
and behavior equivalent to the original trace. 


Lemma 13 (Uniqueness). For all ta, tn, ty € K'(S;), such that (ta, tn, to), 
there exists a unique t € K*(S;), such that t ©% ta, t &” tn, t ©? ty, and 
te V (ta, tn, te): 

Sketch of the proof (Full proof is given in App. A.15): Existence: Con- 


struct t € K'($;), such that for all n € N: ¢(n) af Y (ta(n), tr(m), to(n)). 
Uniqueness: By Lem. 12. 
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Now we have everything to formulate and prove soundness of our cha- 
racterization. 


Theorem 17 (Soundness). Let B C K'(S;) be a BP, N C K*(S;) a CP, 
and AC K'(S;) an AP. Then, for every t € K*(S;), 


t€ANNOB <> Ita € Aytn € Ny ty € B: Y (tastn,ty)A 
EPL NE tht th NES Vata, th) 3 


Sketch of the proof (Full proof is given in App. A.16): 
e =>: Let t. = t, = ty =t and show tg € AAth EC NAt € B, 
be te Ne Ie Rt Ee EAE Ey ee tecand 
be Vast th): . . . 
e <: Since t, € A, ty, ty € K°(9;), and ty &* tn Ata © tyANtn &* br, 
have at, :@ A such that?) 2? t,t, 2" Gat, 3 ty and t~ 
Y (ta, tn, te) by Def. 19 and conclude t, = t € A by Lem. 13. Similar 
reasoning can be applied to show t € N and t € B. 


3.5 Completeness of Property Characterization 


In addition to soundness, we provide also a completeness result for our cha- 
racterization. Therefore, we show that (almost) every set of configuration 
traces can be separated into an activation, connection, and behavioral pro- 
perty. 

Indeed, completeness does not hold for every set of configuration traces. 
In the following, we characterize those sets for which it does. 


3.5.1 Separable Architecture Properties 


A separable architecture property is a set of configuration traces where the 
aspect (activation, connection, and behavior) are independent from each 
other. 


Definition 22 (Separable architecture property). A separable architecture 
property (SAP) for interface specification S; = (C,I,t°,t') € Sy, is a set 
of CTs S C K'(S;), such that activation, connection, and behavior do not 
influence each other: 


Vt €K'(S;),n EN: ((Gta € S: tin mt At, wt) A 


(Btn € S: th A" EA ty et) A (Aty € S: tx EA ~' t)) — tes. 
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Also separable architecture properties are defined by means of a special 
closure property: for each separable architecture properties S we require 
that for each configuration trace t, if there exist traces tg, tn, and ty, such 
that tg is activation equivalent to t, t, is connection equivalent to t, and ty, 
is behavior equivalent to t, then ¢ is also in S. In the following, we provide 
an example of a separable architecture properties. 


Example 18 (Separable architecture property). Figure 24 depicts the idea 
behind SAPs. If there exists an AC which is activation, connection, and 


{pi,p2, pa} ~~ ~{p2,p5} 
X 
ve ee po} 
{(p2, s2)} 
ksy 3: KS 
{p1, p2,p3}- ~~ {p1,p2, ns ~ > ~{(p2, 82) } 
{( ye" {(p1, 81) ‘ ~S{po, {pa}} 
P1, $1 
” {(p1, $1 Yes 7 {Pi,p2} 
{p1,p2,P3}~ ~ {pi,p2,p3}~ ~ _ aan _ — -{(p2, $2) } 


O 
Op Os tp ts 
bb:: BB 


~ {p2,{pa}} 
7 {pi, po} 


p2, $2) 


Figure 24: Separable architecture property. 


behavior equivalent to three other ACs which are part of the SAP, then the 
original AC must also be part of the SAP. In Fig. 24 the AC at the bottom 
is activation equivalent to the left AC, connection equivalent to the top AC, 
and behavior equivalent to the right AC. If the top three ACs are part of a 
SAP, then the bottom one has to be part of the SAP, too. 
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3.5.2. Running Example: Blackboard Guarantee 


In the following, we specify a guarantee of blackboard architectures as a 
separable architecture property over the interface specification Spp. 


Theorem 19 (Blackboard). If for each open (sub-)problem, there exists a 
Knowledge-source (KS) which is able to solve the corresponding problem: 


(vp € bb.op: &(Aks: p € ks.prob A a) ; (20) 


then, it is guaranteed, that the architecture will eventually solve an overall 
problem, even if no single KS is able to solve the problem on its own: 


(v € bb.in = > (p, solve(p)) € bb.os) ‘ (21) 


Proof: (Sketch) The proof is by well-founded induction over the problem 
relation <: We are sure that for each problem eventually a KnowledgeSource 
exists which is capable to solve the problem, Eq. (20). The required sub- 
problems are provided to the BlackBoard by the connection constraint of 
Fig. 19. The BlackBoard will provide these subproblems eventually on its 
output op, Eq. (15). Since the subproblems provided to the BlackBoard are 
strictly less (according to <), Eq. (18), they will be solved and provided by 
the BlackBoard by induction. A KnowledgeSource will eventually be acti- 
vated for each solution, Eq. (20), and connected to the BlackBoard (Fig. 19). 
This KnowledgeSource eventually has all solutions to its subproblems, by 
Eqs. (12) and (13), and will then solve the original problem by Eq. (17). The 
solution is received eventually by the BlackBoard due to Fig. (19). Finally, 
the overall solution is provided by the BlackBoard due to Eq. (14). 


3.5.3 Relative Completeness 


In order to show relative completeness of our characterization we have to 
introduce the notion of activation, connection, and behavior closures for a 
set of configuration traces. 

An activation closure takes a set of configuration traces and adds all 
activation equivalent configuration traces. 


Definition 23 (Activation closure). For a set of CTs A C K*(S;) over 
interface specification 5; € Sy an activation closure close?(A) C K'(S;) is 
defined as follows: 


close*(A) = {t’ € K'(S;) | Ste Arta*t ata’ t} . 
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An important property for an activation closure is that it is indeed an 
activation property. 


Lemma 14 (Activation closure is an activation property). For a set of CTs 
ACK"'(S;) over interface specification S; € S;, close?(A) is an AP. 


Sketch of the proof (Full proof is given in App. A.13): Let ta € close?(A) 
and tn, tp € K*(S;), such that Y(ta,tn,t») and construct t/, € K'($;), such 
that for all n € N, t/(n) a Y(ta(n), tr(m), ty(n)). Then, show that 
be tig th Sta ty SP ip cand te” Y (tagtns te) 

Similar to the activation closure, we can introduce the notion of con- 
nection closure close"(T) C K'(S;) and behavior closure close®(T’) C K'(5;) 
for a set of CTs T C K*(9;) over interface specification S$; € Sy. A similar 
lemma as Lem. 14 can then be proved for these notions. 

Now we have everything we need to proof a completeness theorem for 
our characterization of activation, connection, and behavior properties. 


Theorem 20 (Completeness). Each SAP S$ C K'(S;) for interface specifi- 
cation S; € S; can be uniquely described through the intersection of an AP 
AC K*(S;), CP N CK*(S;), and BP BC K*(S;): 


S=ANNNB. 


Sketch of the proof (Full proof is given in App. A.14): ANNNOBCS: 
Apply close?($), close"(S), close®(,S) to construct A, N, and B, respectively. 
Then show that their intersection is a subset of S by applying Def. 22. 
ANNNB D S: Use reflexivity of =*, ~”, and ~? to conclude ANNNB DS 
by Def. 23. 


4 Verifying Properties of Dynamic Architectures 


In this section, we propose an approach to the verification of properties for 
dynamic architectures based on the theory discussed so far. 

Figure 25 shows the proposed approach to property verification. In a 
first step, components interfaces are specified. Based on the interface spe- 
cification corresponding behavior, connection, and activation properties are 
specified. Finally, an overall architecture property is specified and verified 
against the behavior, connection, and activation properties. 

In the following we discuss the details of specification and verification 
steps. 
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( Interface Specification ) 
a Behavior 
|| 
Constraints ) 
Aca S) 
ed aaa =——> C Guarantee +) 
9 Constraints 
(~ Connection 
—- 
Constraints ) 


Figure 25: Verification approach. 


4.1 Specifying Interfaces 


To specify interfaces, a set of ports and corresponding types of messages 
have to be specified first. This can be achieved by traditional specifica- 
tion techniques such as algebraic specifications [32]. Interfaces can then be 
simply specified by grouping a set of ports. 


4.2 Specifying Activation, Connection, and Behavior Pro- 
perties 


Activation, connection, and behavior properties can then be specified over 
the interfaces. Fig. 26 depicts an overview of the proposed approach to 
specify architecture properties. After specifying activation, connection, and 
behavior properties, the specifications are merged by taking the intersection 
of the corresponding sets of configuration traces. 

The different kind of properties can be specified by CTAs [21]. However, 
since they allow to specify general sets of CTs, they have to be formulated 
in a manner such that the corresponding definitions are satisfied. A general 
heuristics could be, for example, to use implications of the following form: 


General CTA => Property Specific CTA . 


Thereby, the left hand side of the implication is a general CTA while the 
right hand side is one, specific for the kind of property one wants to spe- 
cify. These property-specific CTAs are only allowed to specify activation, 
connection, or behavior, respectively. 
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Interface 
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Connection 
Specification 


Activation 
Specification 


Behavioral 
Specification 


f Universe of 
onf. Traces 


Figure 26: Specifying Dynamic Architectures. 


4.3. Verifying the Guarantee 


The guarantee is specified as general architecture property over the corre- 
sponding interface specification. Again, CTAs can be used to specify the 
guarantee. The guarantee is then verified by showing that the corresponding 
set of configuration traces is a subset of the set specified as the intersection 
of the activation, connection, and behavior properties. 


5 Discussion 


In the following, we briefly discuss our approach and possible limitations. 
Thereby, we critically examine some of its potential weaknesses in more 


detail. 
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Theoretical limitations. One possible weakness concerns the nature of 
our underlying model for dynamic architectures. Def. 17 does not allow 
components to change their interface over time. This could be seen as 
a restriction of the model, however, it was a deliberate decision since for 
now, we did not yet find the need for components to change their interfaces. 
Indeed, it remains an open question whether dynamic interfaces are useful, 
at all. However, if the need for them arises, it should be noted, that the 
underlying model can be adapted to allow for dynamic interfaces as well. 


Methodological limitations. With this text, we provide a formal cha- 
racterization of three different classes of properties for dynamic architec- 
tures. Moreover, with Thm. 17 and Thm. 20 we provide evidence that 
these classes are indeed useful. To verify that a property is indeed of a 
certain class, one has to show that it satisfies the corresponding definition. 
We admit that this could be seen as a potential weakness in that it is not 
always obvious whether a given property indeed satisfies one of the cha- 
racteristic definitions. However, the purpose of this text was to provide a 
clear understanding of these classes which serves as a basis for future work 
concentrating on how to support in the verification of whether a property 
indeed belongs to one of the different classes. 


Practical limitations. A last point which needs to be discussed in more 
detail regards an important aspect of software architectures in general. Our 
approach does actually not provide means to directly specify quality attri- 
butes such as availability or reliability. However, as our example shows, it 
allows us to specify the technical realization of such aspects. Theorem 3.5.2, 
for example, ensures that a problem can be solved also in the absence of 
certain components. This can be seen as one possible implementation (or 
technical definition) of what is sometimes called availability. 


6 Related Work 


Related work can be found in three different areas: 1. Architecture descrip- 
tion languages, 2. Modeling of architectural styles, and 3. Specification of 
constraints for dynamic architectures. In the following we briefly discuss 
each of them. 
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6.1 Architecture Description Languages 


Over the last three decades, a number of so-called Architecture Description 
Languages (ADLs) emerged to support the formal specification of architec- 
tures. Some of them also support the specification of dynamic aspects such 
as Rapide [18], Darwin [19], Dynamic Wright [2, 3], I-ADL [26], xADL [12], 
and ACME [14]. 

While ADLs support the formal specification of architectures, they were 
developed with the aim to specify individual architecture solutions, rather 
than properties for architectures which require more abstract specification 
techniques. Nevertheless, these works provide the conceptual foundation for 
our work since many of the abstractions used in our model are based on the 
concepts introduced by ADLs. 


6.2. Modeling Architectural Styles 


Architectural styles focus on the specification of architectural constraints, 
rather than specific architectures. 

One of the first approaches to formalize architectural styles is discussed 
by Abowd et al. {1]. There, the authors apply a denotational semantics ap- 
proach to software architectures by using the specification language Z [29]. 
Other examples used to specify architectural styles include the Chemical 
Abstract Machine [16] or Wright [2] which allow for the specification of ar- 
chitectural constraints for static architectures. Two further ideas come from 
Moriconi et al. [25] and Penix et al. [27]. Both apply algebraic specification 
to software architectures. Finally, Bernardo et al. [4] use process algebras 
to specify architectural types which can be seen as a form of architectural 
styles. 

While these approaches focus on the specification of architectural con- 
straints rather than architectures, they usually do not allow for the specifi- 
cation of dynamic architectural constraints which is the focus of this work. 
Nevertheless, these works provide many important conceptual insights into 
the specification of architectural constraints on which we build. 


6.3. Specification of Constraints for Dynamic Architectures 


Work in this area is most closely related to our work. 

The approach of Le Métayer [17] applies graph theory to specify ar- 
chitectural evolution. The author proposes the use of graph grammars to 
specify architectural evolution. A similar approach comes from Hirsch and 


230 D. Marmsoler, M. Gleirscher 


Montanari [15] who employ hypergraphs as a formal model to represent sty- 
les and their reconfigurations. While we also apply a graph-based approach 
to model architectural properties, the major difference lies in the specifica- 
tion of behavior. While the discussed approaches focus on structural aspects, 
we aim at a combination of structural and behavioral aspects. 

Another, closely related approach is the one of Wermlinger et al. [31]. 
The authors combine behavior and structure to model dynamic reconfigu- 
rations. One major difference to our work concerns the underlying model 
of interaction. While the authors use an action synchronization commu- 
nication model, our model is based on time-synchronous communication. 
Both communication models have their advantages and drawbacks. Thus, 
by providing a time-synchronous alternative, we actually complement their 
work. 

Recently, categorical approaches to dynamic architecture reconfigura- 
tion appeared such as the work of Castro et al. [10] or Fiadeiro and Lo- 
pes [13]. While these approaches provide fundamental insights into the 
specification of dynamic architecture properties, their model remains impli- 
cit in the categorical constructions. Thus, we complement their work by 
providing an explicit model of dynamic architecture properties. 

Finally, we do not know of any existing work investigating different 
types of properties of dynamic architectures. However, as stated in the 
introduction, this is an important aspect to systematically specify properties 
of dynamic architectures. In this work we provide a formal investigation of 
properties which is another contribution to current literature. 


7 Conclusion 


In this article, we provide a formal notion of properties for dynamic architec- 
tures and investigate different classes of such properties. The major results 
can be summarized as follows: 

e We provide a novel model for dynamic architectures and a formal no- 
tion of properties for this kind of architectures (Sect. 2). Thereby 
an architecture property is modeled as a set of configuration traces 
(Def. 17) which are sequences of architecture configurations (Def. 7). 

e We provide a formal characterization of activation properties, con- 
nection properties, and behavior properties for dynamic architectures 
(Sect. 3). Each property-type is defined as a set of configuration tra- 
ces fulfilling a special closure property: An activation property is not 
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allowed to restrict connections or behavior (Def. 19). A connection 
property, on the other hand, is neither allowed to restrict activation 
nor behavior (Def. 20). Finally, a behavioral property is not allowed 
to restrict activation or connection (Def. 21). 

e We show soundness of our characterization. Thereby, we show that the 
intersection of activation, connection, and behavior properties include 
exactly all expected configuration traces (Thm. 17). 

e Finally, we provide a completeness result for our characterization. 
Therefore we provide a formal characterization of separable architec- 
ture properties and show that each separable architecture property 
can be represented as the intersection of a corresponding activation, 
connection, and behavior properties (Thm. 20). 

Our results can be used to specify and verify properties of dynamic 
architectures. Therefore, we derive a systematic way to specify properties 
for dynamic architectures and apply it to the specification of blackboard 
architectures (Sect. 4): 

e First, component interfaces are specified as a set of ports and corre- 
sponding types. 

e Then, activation, connection, and behavior properties can be specified 
over the interfaces. 

e Then, a guarantee can be specified as a general architecture property. 

e Finally, the guarantee is verified by showing that it is a subset of the 
intersection of the corresponding activation, connection, and behavior 
properties. 

The approach is demonstrated in terms of a running example in which the 
blackboard pattern for dynamic architectures is specified and verified. 

With this work we provide an important step towards our overall goal 
of providing a formal theory of architectural patterns [22]. Future work 
should now concentrate around two major areas: 

e One area of future work concerns the practical usability of the appro- 
ach. As discussed in Sect. 5, future work should concentrate on the 
development of advanced techniques for the specification and analysis 
of the different classes of properties. 

e A second area of future work concerns the application of the approach. 
As demonstrated by the running example, the approach is well-suited 
for the verification of patterns for dynamic architectures. Thus, future 
work in this area should concentrate on the application of the approach 
for the purpose of verifying existing patterns of dynamic architectures. 
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A Proofs 


A.1 Proof of Lem. 1 


According to Def. 11 we have to show that (i) Vp € in(S;,C’): (p ¢ 
in(S;,C") V u(p) = 0) V w(p) = w(B), (ii) VB € in(S;,C’): N(B D)IOUNE C ) # 
0 = (Dp) = Us,en'p p)Nout (Si ,;C’) [(Do), (iii) V(c, p) € in(.9;, C0"), (c’ »P p) € 
N((c,p)): cE C! Ad € C, and (iv) V(c,p) € out(S;,C’): u((c,p)) 40 => 
cEeC’: 

(i) Vp € in(S;,C"): (B € in(S;,C") V ub) = B) V HB) = p(B): Since 
Vp € in(S;,C"): u(p) = (A). 

(ii) Vp € in(S;,C’): N(p) M out(S;,C’) #~ oO —- pp) = 
Usenpynout(s;,c7) Ho): Let p € in(S;,C”’) and assume N(p) 
out(S;,C’) #~ 0. Thus, conclude N(p) #4 @ and have p(p) = 
Usnen(p) (Po) = Use (p)ynout($:,C") (Po) by Def. 7. 

(iii) V(c,p) € in(S;,C’), (¢,p') € N((ce,p)): cE C’ Ad € C’: By De. 7. 

(iv) V(c,p) € out(S;,C’): w((c,p)) #0 = > c € C’: Since V(c,p) € 
out(.S;,C”): c € C’ by Def. 6. 


A.2 Proof of Prop. 1 


Existence: Let “Vike Rake) <S ACTON): Saath Ce <7, 
N: in(S;,C’) > g(out(.S;,C”’)), such that N((c,p)) = 
if / 

8 ey Cn, and pt € port(S;,C’), such 
{(c,p') € Nn((e,p)) | EC} ifeec, 
Li(p) if pe out(S;, Ch) 
if p rm) ‘ iz) 4 
that j(p) = 0 ve euEe C’) \ out(S;, C;) 
Usen(p) L(Po) if p € ine(Si, V(ha kn, ky)) 
La(D) if p € ino( Si, \ Chas kin, kp)) 

We show (i) C’ C C, (ii) N: in($;,C’) > jae (iii) pe € 
port(S;,C’), and (iv) Vpi € in(S;,C"): N(pi) # = [u( pi) = 
Uss,en(p;) Ho); to have Y¥ (Ka; kn, ky) € K(S;) by Def. a 

(i) C’ CC: Since C! = Ch and CZ, CC. 
(ii) N: in(S;,C’) > e(out(S;,C’)): We show well-definedness of N: 
e Existence: Let (c,p) € in(.S;,C’). 
— Case c ¢ C): N((c,p)) = C out(S;, C’). 
— Case c € Ch: N((c,p)) = {(c',p’) € Na((e,p)) | eo € C4} C 


out(S;, C"). 
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e Uniqueness: Let (c,p) = (c’,p’) € in($;, C’). 
— Case c ¢ C!: First have N((c,p)) = @. Then, since ¢ = 
c have c ¢ "Cl and conclude N((c’,p’)) = 0. Thus, have 
N((c,p)) = 9 = N((¢,p’)). 
— Case c € C): First have N((c,p)) = {(c",p") € Nn((c,p)) | 
c € C’}. Then, since c’ = c have c € C’, and conclude 
N((c,p')) = {(c",p") € Na((e,p’)) | ce” € C'}. Thus, 
since (c,p) = (c,p’) conclude N,((c,p)) = Nn((c,p’)) and 
thus have N((c,p)) = {(c’,p") € Nrl((c,p)) | d € Ch} = 
{(c",p") € Nn((c',p’)) |e € C'} = N((c',p’)). 
(iii) V(e,p) € in(S;,C’),(co,Po) € N((c,p)): Tp, C Tp: Let (e,p) € 
in(.S;,C”) and conclude (co, Po) € Nn((c,p)) by Def. 12. Thus, since 
kn € K(S;) conclude T,, C T, by Def. 7. 
(iv) fs € port(S;,C’): We show well-definedness of pu: 
e Existence: Let (c,p) € port(S;,C’). 
— (e,p) € out(S;,C;,): u((c,p)) = Ho((c, Pp) E Tp. 
— (cp)e leas outta O,)> u((c,p)) = 


oid since V(Co, Po) € Nake oy): te, 
= (c, p) € ino(Si, Y (ka; kn, kp)): u((c, p 
e Uniqueness: Let (c,p) = (¢,p’) € in(S;, C’). 

— (c,p) € out(S;,Cf): First have p((c,p)) = p((c,p)). Mo- 
reover, since (c,p) = (c’,p’) have (c’,p’) € out(S;,C}) and 
conclude p((c’,p’)) = py((c',p’)). Thus, since Ho((c, p)) 
t((c',p")) conclude pu((c,p)) = po((e,p)) = bo((c',p’) 
u((c',p’)). 

— (c,p) € out(S;,C"’) \ out(S;,C;): First have p((c,p)) = 9. 
Moreover, since (c,p) = (¢,p’) have (c’,p’) € out(S;,C’) \ 
out(S;,C;) and conclude p((c,p’)) = 0. Thus, since 
Ho ((c,p)) = He((c',p’)) conclude pu((c,p)) = 0 = w((¢,p’)). 

— (cep) € ine(Si, ¥(ka,kn,ky)): First have p((c,p)) = 
Ussen((ccp)) H(Bo)- Moreover, since (c,p) = (c',p’) have 
(cp) € inc(Si, V(ka, kn, kp)) and conclude p((c’,p’)) = 
Us.en((cp ry) l(Bo). Thus, since N((c,p)) = N((c',p’)) con- 
clude u((c ,p)) = Usen((ep)) (Po) = Usen((c'p')) (Po) = 
u((c', p’)). 

—(c¢p) € ing iy Vihag es We): First have p((c,p)) = 
Ha((c,p)). Moreover, since (c,p) = (c’,p’) have (c,p’) € 
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ino(Si, V(ka, kn, kp)) and conclude p((c’,p’)) = pa((c',p’)). 
Thus, since fa((c,p)) = Mal(c,p’)) conclude p((c,p)) = 
Mal (e,P)) = Ha((e',P')) = (Ce, P')). 

(v) VB: € in(S;,C): NG) #0 — uh) = Unengy ult): Therefore, 
let p; € in(S;,C’) and assume N(p;) #4 0. Thus, by Def. 10, p; € 
ine(Sj, Y (ka; kes kp)) and p(p;) = Usen(p) [(Po) by definition. 
Uniqueness: Let (C”,N’,y') € K(S;) such that C” = 

Cl, N’: in(S;,C”) +  g(out(S;,C”)), such that N’((c,p)) = 
0 ifc¢ Ci, 
{(c,p') € Nn((ce,p))|¢ €C"} ife eC’ 

L(p) if p E out(S;, Ci) 

if pE out(S;, Cc”) \ out(S;, Ch) 

Us.en(p) L' (Po) if p c ine(S;, V Gas ky)) 

Ha(P) if p € ino(Si, Y (ka; kn, kp)) 

We show (C”, N’, 1’) = (C’, N, ps): 

e C” =C": Since C” = Ch and C’ = Ci, conclude C” = C". 

e N’ = N: First note that in(S;,C”) = in(S;,C’) and out(S;,C”) = 
out(.5;,C’). Let (c,p) € in(S;,C”). 

— Case c ¢ C},: Have N’((c,p)) = and N((c,p)) = 0 and conclude 
N'((c,p)) = N((cy)). 

— Case c € Ci: Have N’((c,p)) = {(c,p’) € Nn((c,p)) | ¢d € C”} 
and N((c,p)) = {(¢,p’) € Nn((c,p)) | ¢ € C’} and since C” = C’ 
conclude N’((c,p)) = N((c,p)). 

e yw’ = uw: First note that port(S;,C”) = port($;,C’) and let (c,p) € 
port(.S;, C”’). 

— (¢,p) € out(S;,C;): Have p'((c,p)) = po((c,p)) and p((c,p)) = 
Ln((c, p)) by definition and conclude p'((c,p)) = w((c, p)). 

— (e,p) € out(S;,C”) \ out(S;,Ch): First have p’/((c,p)) = @ by 
definition. Moreover, since out(.S;,C’) = out(S;,C”) have (c, p) € 
out(.S;,C”) \ out(S;, Cf) and conclude p((c,p)) = 0 by definition. 
Thus, conclude p’((c, p)) = u((c, p)). 

— (cp) €  inc(Si, ¥(Ka,kn,kp)): First have p'((c,p)) = 


and pw’ € port(S;,C”), such 


that p’(p) = 


Ups.eNn"((cp)) (Bo) and ((c,p)) a Ussen((cp)) (Po) 
by definition. Thus, since N’ = WN and Vp € 
out(S;,C”) =  out(S;,C’): w’(p) = ~ w(p) conclude 


Lu ((c,p)) = Us,enr((:p)) H’ (Bo) = Upsen (py) Ho) = H((e, p))- 
— (c,p) € ing(Si, V¥(Ka, kn, ky)): Have p'((e,p)) = pa((e,p)) and 
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u((c,p)) = Mal(e,p)) by definition. Thus, conclude p’((c,p)) = 
L((c, p)). 


A.3 Proof of Lem. 2 


For a function f: A — B, in the following, we denote with dom (f) eA 


the domain of f and with ran (f) “Bits range. 


Let (C’,.N, #) = Y (Ka, ka, ka). We show kg = (C’, N, 1). 

e C’=Ci: By Def. 12. 

e N=N,: By Def. 12, N: in(S;,C’) > g(out(S;,C’)) and since C’ = C’, 
conclude dom (NV) = dom (N,) and ran (NV) = ran (N,). We show Vp € 
in(S;, C’,): N(p) = Na(p) to conclude N = Ng. Therefore let (c,p) € 
in(S;,C%) and conclude c € C/. Thus, have N((c,p)) = {(c,p’) € 
Na((c,p)) | ¢ € C’} = Na((c,p)) by Def. 12. 

© 4 = pa: By Def. 12, w € port(S;,C’) and since C’ = C/ con- 
clude dom (jz) = dom (fq) and ran(~) = ran(U,_). We show Vp € 
port(S;,C0”,): u(p) = pfa(p) to conclude yp = pg. Therefore let 
p € port(S;,C’). 

— Case p € out(S;,C!,): By Def. 12, u(p) = ta(p). 

— Case p € in.(S;,ka): Since C’ = Cl and N = N, 
conclude ing(.S;, V hash Rey) = CinnS 5. eel Thus, have 
MP) = Usen(a Ho) by Def. 12. Thus, since Wp, € 
out(S;,C%,): u(po) = balBo) and since N(p) = N,(p) have 
U,5,en(p) Ho) = Usena(p) Ha(Po) and conclude p(p) = 

io€Na(B) Hta(Bo). Moreover, since p € in.-(S;,ka) conclude 
Na(p) # 9 by Def. 10. Thus, have fa(P) = Uny,en,(p) Ma(Bo) by 
Def. 7 and since 14(6) = Up,en,(p) Ha(Bo) conclude ju(p) = Ha(P). 

— Case p € ing(9;,ka): Since C’ = Cl and N = N, conclude 
ing (Si, ¥ Gai Racke:)) = ing(S;,ka). Thus, have u(p) = pa(p) by 
Def. 12. 


A.4 Proof of Lem. 3 


Reflexivity: For every architecture configuration k = (C’, N, 1) € K(S;) we 
have C’ = C’ and thus k *% k by Def. 13. 

Symmetry: Let k = (C’, N,) € K(S;) and k’ = (C”, N’,n’) € K(S;), 
such that k ~* k’. By Def. 13 we have C’ = C” and thus k’ ~*% k by Def. 13 
again. 
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Transitivity; Let k = (C',N,p), k = (C"",N',p’), and k’ = 
(C’”,N”,w") three architecture configurations over interface specification 
5S; € S; such that k =* k’ and k! =* k". By Def. 13 we have C’ = C” and 
C” =C™. Thus, conclude C’ = C’ and have k ~* k" by Def. 13. 


A.5 Proof of Lem. 4 


By Def. 12 have [V (ka, kn; ke)] = [Ka] Thus, by Def. 13 conclude 
¥ (ha: Kn, ky) a Ka. 


A.6 Proof of Lem. 5 


Reflexivity: Let k = (C’,N,u) € K(S;). We have Vp; € in(S;,C’ 
OC’): N(p;) = N(p;). Moreover, since in(.S;,C’ \ C’) = 0, we conclude 
Vp; € in(S;,C’ \ C’): N(p;) = 0. Thus, conclude k =" k by Def. 14. 
Symmetry: Let k = (C’, N, w) and k’ = (C”, N’, p’) be two architecture 
configurations over interface specification S$; € S;, such that k =" k’. Thus, 
have Vp; € in(S;, C’ fal Cry: N(p;) = N' (pi), Vp € int Ss." \ Cc"): N(pi) = 
0, and Vp; € in(.S;,C” \ C’): N’(p;) = @ by Def. 14 and conclude Vp; € 
in(S;,C” MC"): N'(p;) = N(p;), VO; € in(S;,C” \ C’): N’(6;) = 0, and 
Vp; € in(S;,C’ \ C”): N(p;) =. Thus, have k’ =" k by Def. 14. 
Transitivity: Let k = (C',N,u), k = (C",N'; yp’), and k” = 
(C’”, N", 2") be architecture configurations over interface specification 5; € 
S;, such that k =" k’ and k! &" k”. We show k &" k”. According to 
Def. 14 we have to show (i) Vp; € in(.S;,C’ NC”): N(p;) = N”(p;), (ii) Vi € 
in(S;,C’ \ C”): N(p;) = @, and (iii) Vd; € in(S;,C” \ C’): N”(p;) = @: 
(i) Vp; € in(S;,C’ NC”): N(p;) = N”(p;): Therefore, let p; € in(S;,C’N 
Cc"). 
e Case p; ¢ in(S;,C”): Since p; € in(S;,C’) and k =” k’ have 
N(p;) = @ by Def. 14. Moreover, since p; € in(.S;,C’”) and k’ =” 
k" have N”(p;) = 0 by Def. 14. Thus, conclude N(p;) = 0 = 
N" (Gj). 
e Case p; € in(.S;,C”): Since p; € in(S;,C’) and k =" k’ have 
N(p;) = N'(p;) by Def. 14. Moreover, since p; € in(.S;,C’”) and 
ki =” k” have N’(p;) = N”(p;) by Def. 14. Thus, conclude 
N(pi) = N'(Bi) = N" (Bi). 
(ii) Vp; € in(S;,C’ \ C’”): N(p;) = @: Therefore, let 6; € in(S;,C’ \ C”). 
e Case p; ¢ in(S;,C”): Since p; € in(S;,C’) and k =” k’ have 
N(p;) = by Def. 14. 
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e Case p; € in(S;,C”): Since p; € in(S;,C’) and k =” k’ have 
N(p;) = N’(p;) by Def. 14. Moreover, since p; ¢ in(S;,C’”) and 
ki =” k” have N’(p;) = 0 by Def. 14. Thus, conclude N(p;) = 
N'(p;) = 0. 

(iii) Vp; € in(S;,C” \ C’): N”(p;) = 0: Therefore, let p; € in(S;,C’” \ C’). 

e Case p; ¢ in(S;,C”): Since p; € in(S;,C’”) and k’ =” k” have 
N"(p;) = 0 by Def. 14. 

e Case p; € in(S;,C”): Since p; € in(S;,C’”) and k’ =” k” have 
N"(p;) = N'(p;) by Def. 14. Moreover, since p; ¢ in(S;,C’) and 
k =" k’ have N’(p;) = @ by Def. 14. Thus, conclude N”(p;) = 
N'(p;) = 0. 


A.7 Proof of Lem. 6 


Let (C’, N, 2) = Y (ka, kn, ky). We show (i) Vp; € in(S;,C’ Ch): N(p;) = 
Nn (pi), (ii) Vp; € in(.S;, C” ¥ Ch): N(pi) = 0, and (iii) Vpi € in(S;, C7, \ 
C’): Nn(pi) = 0; to conclude Y (ka, kn, ky) #” kn by Def. 14: 

(i) Vpi € in(.S;, C" N ie N(pi) = Nn (pi): Let (ey.05) € in(.Si, C’ N Cr) 
and conclude (c¢;, pj) € in(S;,C”) and (c¢;,p;) € in(;, C),). 

e N((c:,pi)) C Nn((ci, pi)): Let po € N((ci,pi)). By Def. 12 have 
Bo © Nn (Ci; Pi))- 

e Nn((c,pi)) CG N((ci,pi)): Let (€o,P0) € Nn((ci,p;i)). Since 
(ci, pi) € in(S;,C/,) and (co, Po) € Nn((ci, pi)) have c; € Ci, and 
Co € Cl by Def. 11. Thus, since c; € C/, and c, € C! conclude 
(Co, Po) © N((ci, pi)) by Def. 12. 

(ii) Vp; € in(S;,C’ \ CL): N(p;) = 0: Let (c,p;) € in(S;,C’ \ Cl) and 
conclude (c,pi) €¢ in(S;,C/,). Thus, have c; ¢ C!, and conclude 
N((ci, pi)) = 9 by Def. 12. 

(iii) Vo; € in(S;,Ch, \ C’): Nn(pi) = O: Let (G,pi) € in(S;,C}, \ C’) and 
conclude (c¢;, pi) ¢ in(.$;,C’). Assume N,,((cj,pi)) 4 O and let (co, po) € 
N,((ci, pi)). Since (c;, pi) € in(S;,C!,) and (co, Po) € Nn((ci,pi)) have 
c; € Cl and co € Cl, by Def. 11. Thus, since C’ = C’, by Def. 12 
conclude c; € C’ which is in contradiction to (c;,p;) € in(S;,C’). 


A.8 Proof of Lem. 8 

Let (C’, N, pw) = Y Ras ters Fp) We show (i) Vp € out(S;,C’ 1 Ch): w(p) = 
Lw(p), (ii) Vp € out(S;,C’ \ Cf): w(p) = O, and (iii) Vp € out(S;,CF \ 
C’): p(p) = 0; to conclude Y (Ka, kn, ky) ©? ky by Def. 15: 
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(i) Vp € out(S;,C’M Ci): wp) = po(): Let p € out(S;,C’M Ch) and 
conclude p € out(5;,C;). Thus, have u(p) = p(p) by Def. 12. 
(ii) Vp € out(S;,C’ \ C)): u(p) = 0: Let p € out(S;,C’ \ Ch) and conclude 
p € in(S;,C’) \ in(S;, Cf). Thus, have ju(p) = 0 by Def. 12. 
(iii) Vp € out(S;,C; \ C’): ws(p) = 0: Let (c,p) € out(S;,C; \ C’) and 
conclude (c, p) € in(S;,C;) and (c,p) ¢ in(S;,C’). Assume jp((c, p)) # 
. Thus, since (c,p) € out(S;,C%) have c € C!, by Def. 11. Moreover, 
have C’ = C!, by Def. 12 and since c € C/, conclude c € C’. Thus, have 
a contradiction with (c, p) ¢ in(.S;, C’). 


A.9 Proof of Lem. 9 


Reflexivity: Let k = (C’, N, uw) € K(S;). We have Vp € in(S;, C’NC’): p(p) = 
u(p). Moreover, since in(S;,C’ \ C’) = @, we conclude Vp € in(.S;,C’ \ 
C’): u(p) = 0. Thus, conclude k +? k by Def. 15. 
Symmetry: Let k = (C’, N,w) and k’ = (C”, N’, p’) be two architecture 
configurations over interface specification S; € S;, such that k +? k’. Thus, 
have Vp € in(S;,C’ 1. C”): u(p) = p'(p), Vp € in(S;, C’ \ C”): u(p) = 0, and 
Vp € in(S;,C” \ C’): p’(p) = 0 by Def. 15 and conclude Vp € in(S;,C” N 
C"): p(B) = wp), VB € in(S;,C” \ C’): p’(p) = 0, and Vp € in(S;,C" \ 
C"): w(p) = 0. Thus, have k’ ~° k by Def. 15. 
Transitivity: Let k = (C’,N,pu), kb = (C"",N',p’), and kv” = 
(C’””, N", uw’) be architecture configurations over interface specification S; € 
S;, such that k =? ki and ki x k’. We show k = k”.  Accor- 
ding to Def. 15 we have to show Vp € in(S;,C’N C’”): u(p) = pw" (p), 
Vp € in(S;, C0’ \ C”): w(p) = 0, and Vp € in(S;,C” \ C’): pw" (p) = 0. 
e Vp € in($;,C’NC”): u(p) = wv" (p): Therefore, let p € in(S;,C’NC”). 
— Case p ¢ in(S;,C”): Since p € in(.S;,C’) and k x° k’ have u(p) = 
@ by Def. 15. Moreover, since p € in(.S;,C’”) and k’ ~° k” have 

uu (p) = 0 by Def. 15. Thus, conclude p(p) = 0 = p’(p). 
— Case p € in(S;,C”): Since p € in(S;,C") and k x? k’ have pu(p) = 
(pb) by Def. 15. Moreover, since p € in(.9;,C’”) and k! x? k’’ 
have p’(p) = w"(p) by Def. 15. Thus, conclude p(p) = p’(p) = 


e Vp € in(S;,C’ \ C’’): u(p) = 0: Therefore, let p € in(.S;,C’ \ C’”). 
— Case p ¢ in(S;,C”): Since p € in(S;,C") and k ? k’ have pu(p) = 
0 by Def. 15. 
— Case p € in(S;,C”): Since p € in(S;,C") and k x? k’ have pu(p) = 
(pb) by Def. 15. Moreover, since p ¢ in(.9;,C’) and k! x? k!’ 
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have p'(p) = 0 by Def. 15. Thus, conclude pu(p) = py’ (p) = 0. 


e Vp € in(S;,C’” \ C’): uw" (p) = 0: Therefore, let p € in(S;,C”” \ C’). 


— Case p ¢ in(S;,C”): Since p € in(S;,C’”) and k’ ~° k” have 
uw’ (p) = 0 by Def. 15. 

— Case p € in(S;,C”): Since p € in(S;,C’”) and k’ ~° k” have 
wu" (p) = w'(p) by Def. 15. Moreover, since p ¢ in(S;,C’) and 
k > k! have p'(p) = 0 by Def. 15. Thus, conclude p(s) = 
u(p) = 0. 


A.10 Proof of Lem. 10 


Let ke = (C1, Na, Ha), kn = (Ci, Nn, bin), and kp = (Cf, Np, uy) and assume 
Vikas kin, kp). 


We show ka &' kn: According to Def. 16 we have to show (i) Vp € 


in(Si,CZ Ch): Ha(B) = Mn(B), (i) VP € in(S;,CQ \ Ch): Ha(B) = 0, and 
(it) Vp € in(S,,C4\ CL): tin(B) = 6. 
(i) Vp € in(S;, CLAC!,): Wa(p) = uUn(p): Let p € in(S;,C,.C},). According 


(iii 


YS 


NS 


to Def. 11 we have (p ¢ in(S;,C4) V Ha(p) = 9) A (p ¢ in(S;, C1) V 
tin 8) = 8) A (6 ¢ in(Si,Ch) V ja(B) = 8) oF BE in(Si,CL) AD € 
in(Si, Ch) A pe in(Si, Ch) A [a(P) = Un(B) = bo(p). 
© Case (6 ¢ in(S, CL) V ald) = 8) A (B ¢ in(Si,Ch) V pal) = 

0) A(b ¢ in(S;, Ch) V ue(p) = 0): Since p € in(.S;,CLNC/,) have p € 

in(.S;,C’,) and since p ¢ in(S;,C/,) V Ua(p) = 0 by case assumption, 

conclude fia(p) = 0. Moreover, since p € in(.S;,C/ Ci) have p € 

in(.S;, C!,) and since p ¢ in(S;, C/,)V n(p) = 0 by case assumption, 

conclude pin(p) = 0. Thus, have pia(p) = 0 = Ln(p). 

e Case p € in(S;,CZ) Ap € in(S;,C)) Ap € in(S;,Ch) A pal(h) = 

Lin (p) = Ly(p): Conclude fa(p) = fn (p) from case assumption. 
Vp € in(9;,C!, \ Cy): ua(p) = 0: Let p € in(S;, C’, \ Ci). According to 
Def. 11 we have (p ¢ in(S;,C4) V Ha(b) = 0) A (6 € in(S;, Ch) V Un(P) = 
0) A (p ¢ in(Si, C5) V po(p) = 0) or p € in(S;,C1) Ap € in(S;,C)) Ape 
in(S;,C}) A Ha(b) = Un(p) = “o(B). Moreover, since p € in(.S;,C/, \ C7) 
have p € in(S;,C/) and conclude (p ¢ in(S;,C%,) V Ha(p) = 0) A (6 ¢ 
in(S;,C},) V Un(b) = 0) A (6 ¢ in(S;, C4) V 40(6) = 0). Thus, since 
p € in(S;,C") conclude jua(p) = 0. 
Vp € in(S;,C%, \ C1): un(p) = 0: Let p € in(S;,C!, \ C!). According to 
Def. 11 we have (p ¢ in(S;,C4) V Ha(b) = 0) A (6 € in(S;, C),) V Un(p) = 
0) A (p € in(.S;, Ch) V no(p) = ) or p € in(S;,C1) Ap € in(S;,CL) Ape 
in(S;,C%) A Ha(P) = Hn (P) = Ho(p). Moreover, since p € in(S;, C7, \ Ca) 
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have p € in(S;,C/,) and conclude (p ¢ in(S;,C%,) V Ha(b) = 0) A (6 ¢ 
in(S;,C)) V un(b) = 0) A (6 ¢ in(S;, Ch) V 4o(p) = 0). Thus, since 
p € in(S;, C!,) conclude pn(p) = 0 

A similar argument can be used to show ky, = ky. 


Finally, since kg = ky and ky, &' ky conclude ka =* ky by Lem. 9. 


A.11 Proof of Lem. 11 


Letokg = (Cy, Navies. = (Caer in). Sud Ry = (CNG ie) ond 
Y(k, Kahr) = Cl IN, fh): 

We show ky ~* (ka; kin, kp): By Def. 16 we have to show Vp € 
in(Si, C4 a C"): Ma(b) = pp), VP € in(S:,Cy ‘ Cc"): Ma(p) = 0, and 
VB € in(S;,C"\ CL): up) = 0. 

e Show Vp € in(S;,C1.NC"): ta(p) = u(p): Therefore, let p € in($;,C4,N 
C") and conclude  € in(.S;, C/,) and p € in(S;, C’). 
— Case p € in,(Si, Vea easioe)): Conclude (fp) = pMal(p) by 
Def. 12. 
— Case p € ine(Si, NV (eas hes hp): By Def. 10 have N(p) 4 @ and 
conclude f € in(S;,C/,) and N,(p) N out(S;,C!,) 4 0 by Def. 12. 
Thus, since p € in(.S;, C’,) Nin(S;, C/,) and N,(p)Nout(S;, C,) 4 0 
have pa(P) = Us,en,(pynout(s;,0%,)nout(s;,07) He(Po) by Def. 11. 
Moreover, have N,,(p) M out(S;,C’) = N(p) by Def. 12 and 
Vp € out(S;,Ch): u(p) = po(p) by Def. 12. Thus, conclude 
Usiceivn(p)nout( sich, nout(si,c}) Ho(Po) = Uncen (pynout(s;.cj) H(Po)- 
Moreover, have Vp € out(S;,C%) \ out(S;,C}): u(p) = @ by 
Def. 12 and conclude Us. (pynout(S;,C2) L(Bo) = Uy,en (py H(Po)- 
Thus, have La(P) = Uso Na (p)Mout(S;,C%,)Nout(S;,C2) Ly (Bo) = 
U,s,en(p) Ho) and since 14(6) = Up eng) Ho) by Def. 12, con- 
clude pla(p) = p(P). 
e Show Vp € in(S;, C4, \ C’): a(p) = 0: First, have C’ = C!, by Def. 12 
and conclude C/ \ C’ = @. Thus, have Vp € in(.9;,C!, \ C’): ua(p) = 0. 
e Show Vp € in(S;,C” \ C4): u(p) = 0: First, have C’ = C/, by Def. 12 
and conclude C/, \ C’ = @. Thus, have Vp € in(.$;,C’ \ C“,): u(p) = 0. 

We show k, = Vike kn, ke) From Lem. 10 have k,, +’ kg and since 
kg Waiters ky) conclude k, =? Caste, ky) by Lem. 9. 

We show ky x* N Ras kn, ky): From Lem. 10 have k, =* k, and since 
ka Y (ka, hig ky) conclude ky ~* Vikas kn, ky) by Lem. 9. 
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A.12 Proof of Lem. 12 


Let k = (C", N, ) and k’ = (C”, N’, ’) two architecture configurations over 

interface specification S; € S7. 

— : Assume k = k’. We show (i) k =* k’, (ii) k =” k’, (iii) kw? kK’, 

and (iv) k x k’: 

(i) k = k’: Since C’ = C” have k ~* k' by Def. 13. 

(ii) k =” k’: Since N = N’ conclude Vp; € in(S;,C’ NC”): N(p;) = 
N'(p;). Moreover, since C’ = C” have C’ \ C” = @ and C” \ C' = 9. 
Thus, conclude Vp; € in(.S;,C’ \ C”): N(p;) = 0 and Vp; € in(S;,C” \ 
C"): N(p;) = 0. Finally have k =" k’ by Def. 14. 

(iii) k x? k’: Since p = p' conclude Vp € out(S;,C’NC”): (p) = py! (p). Mo- 
reover, since C’ = C” have C’\C” = 0 and C’”\C’ = 0. Thus, conclude 
Vp € out(S;,C’ \ C”): u(p) = @ and Vp € out(9;,C” \ C’): p’(p) = 0. 
Finally have k ~° k! by Def. 15. 

(iv) k = k’: Since wp = yp’ conclude Vp € in(S;,C’N C"): u(p) = p'(p). 
Moreover, since C’ = C” have C’ \ C” = @ and C” \ C’ = @. Thus, 
conclude Vp € in(.S;, C’\C”): (6) = 0 and V6 € in(S;,C”\C"): p’(p) = 
). Finally have k =* k’ by Def. 16. 
< : Assume k = ki Ak &” kW Ak = hk’ Ak & Kk’. We show 

(i) C! =", (ii) N = N’, and (iii) uw = p’; to have k = Kk’: 

(i) C’ =C": Since k =* k! have C’ = C” by Def. 13. 

(ii) N = N’: From C’ = OC” have dom(N) = in(S;,C’) = in(S;,C”) = 
dom (N’) and ran(N) = g(out(C’, S;)) = g(out(C”, S;)) = ran (N’). 
We show that Vp € in(S;,C"’) N in(S;,C”): N(p) = N'(p): Therefore, 
let p € in(.S;,C0’NC”) and since k =" k’ have N(p) = N'(p) by Def. 14. 

(iii) w = pw: From C’ = C” have dom(m) = port(C’,S;) = 
port(C”,S;) = dom(y’) and ran(w) = o(M) = ran(y’). We show 
that Vp € port(S;,C’) M port(S;,C”): u(p) = w’(p): Therefore, let 
p € port(S;,C’ NC”) and since k ~° k! have (p) = p!(p) by Def. 15. 


A.13 Proof of Lem. 14 


By Def. 19 we have to show that for all tq € close®(A) and tn,t, € K(S;), 
such that Y(ta,tn,tp), there exists a t/, € close?(A), such that t), = ta, 
tl, ©” tn, t, © ty, and t, =* Y(ta,tn, ty). Therefore, let ta € close*(A) 
and be € "K#(S;), such that Y(ta,tn,t)), and conclude that for all n € N, 
Y(ta(n), tn(n), ty(n)) by Def. 18. Then, construct t/, € K'(S;), such that for 


alln EN, ti (n) “ Y(ta(n), tr(m), ty(n)). First, note that t/, is indeed 
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a valid configuration trace: Since Vn € N: Y (ta(n),tr(n), to(n)), conclude 
that Y(ta(n),tn(n),tp(n)) is a well-defined architecture configuration for 
every n € N by Def. 12. 

We now show ¢/, € close?(A): Since tg € close?(A) have 3t”) € A: tl!) x 
ta At" s* ta by Def. 23 and conclude that for all n € N, t/(n) % ta(n) 
and tq() = ta(n) by Def. 18. Since t” € A, we show (i) tl, = t” and 
(ii) t!, =" t! to conclude t/, € close?(A) by Def. 23. 

(i) t), = t/: From construction have Vn € N: t),(n) &% ta(n) by Lem. 4. 
Thus, since Vn € N: t!(n) = ta(n) have Vn € N: t)(n) &* t(n) by 
Lem. 3 and conclude t/, ~* t! from Def. 18. 

(ii) tf, = t%: From construction have Vn € N: t4(n) wu? ta(n) by Lem. 11. 
Thus, since Vn € N: t@(m) ©" ta(n) have Vn € N: t,(n) &* tg(n) by 
Lem. 9 and conclude t/, ~' t! from Def. 18. 

We conclude by showing (i) t, © ta, (ii) t, &” tn, (iii) t, ©? ty, and 
GY) tees Y estaity 

(i) t, ©* ta: From construction have Vn € N: t/,(n) ~*% ta(n) by Lem. 4 
and conclude t/, &* ty, by Def. 18. 

(ii) t!, &" ty: From construction have Vn € N: t),(n) &" ty(n) by Lem. 6 
and conclude t/, &" tn by Def. 18. 

(iii) t/, ~° t: From construction have Vn € N: t,(n) ~° t)(n) by Lem. 8 
and conclude t!, ~° ty by Def. 18. . 

(iv) t, = Y(ta,tn, ty): From construction have Vn e€ N:tj(n) 
Y (ta(n), tr(m), to(n)) by Lem. 11 and conclude t, &* Y(ta,tn, ty) by 
Def. 18. 


A.14 Proof of Thm. 20 
ef def 


Let A & close?(S), N a close"(S), and B = _ close®(S) and 
note that A is a valid AP, N a valid CP, and B a valid BP by Lem. 14. 
We now show ANNO B=S. 
e ANNOBCS: Therefore, assume t € ANN B: Since t € A, 
have t € close?(S) from construction and conclude Jt, € S: ta 
t\ tq ~ t by Def. 23. Moreover, since t € N, have t € close"(S) 
from construction and conclude Jt, € S: ty &" tA ty & t by Def. 23. 
Moreover, since t € B, have t € close®(S) from construction and 
conclude Jt, € S: ty ¥° t At) ©’ t by Def. 23. Therefore, since S' is a 
SAP, conclude t € S by Def. 22. 
e ANNNB2QS: Therefore, assume t € S. From Lem. 3 have t =* t 
and from Lem. 9 have t = t. Thus, since t € S, have t € close?(S) by 


On Activation, Connection, and Behavior in 
Dynamic Architectures 247 


Def. 23 and conclude t € A by construction. Moreover, have t &” t by 
Lem. 5 and t = t by Lem. 9. Thus, since ¢t € S, have t € close"(S) by 
Def. 23 and conclude t € N by construction. Finally, have t +? t by 
Lem. 7 and t =’ t by Lem. 9. Thus, since ¢ € 9, have t € close®(,S) by 
Def. 23 and conclude t € B by construction. 


A.15 Proof of Lem. 13 


Bristence: Spe (Sots tat A ight S at BV atisth): 
Therefore, let t € K‘(S;), such that for all n € N: ¢t(n) = 
Y(ta(n),tn(n),ty(n)). Note that ¢ is well-defined: Since Yn € N: Y 
(ta(n), tn(m), to(m)), conclude that Y(ta(n),tn(m), to(n)) is a well-defined ar- 
chitecture configuration for every n € N by Def. 12. We show (i) t &% ta, 
(ii) £ =" tn, (ili) t ~? te, and (iv) t=? Y (ta, tn, te): 
(i) t &* tg: From construction have Vn € N: t(n) ~* ta(n) by Lem. 4 and 
conclude t ¥° tg by Def. 18. 
(ii) t &” ty: From construction have Vn € N: t(n) =” t,(n) by Lem. 6 
and conclude t &” t, by Def. 18. 
(iii) t ~° t): From construction have Vn € N: t(n) x® t,(n) by Lem. 8 and 
conclude t ¥° t, by Def. 18. 


(iv) t =! Wiiatacte): From construction have t(n) 7» 
Y (ta(n),tr(n), to(n)) by Lem. 9 and conclude t ®' Y(ta,tn, ty) 
by Def. 18. 


Uniqueness: Vt! € K'(S;): ttt Ate t, Ate tAt x ¥ (ta, tris tp) => 
t' = t. Therefore, let t’ € K*(S;) and assume t/ ~° ta, =” ty, t x ty, 
and t’/ ~' Y(ta, tn, ty). Then have Vn € N: t/(n) © ta(n) At'(n) &” tn(n) A 
t'(n) ©? ty(n) At'(n) &* Y(ta(n), tr(n), to(n)) by Def. 18. We show that for 
all n € N we have (i) t/(n) &* t(n), (ii) t/(n) &” t(n), (iii) U(n) x? t(n), and 
(iv) t'(n) = t(n) to have Vn € N: t/(n) = t(n) by Lem. 12 and conclude 
t! = t by Def. 18. 
(i) t/(n) &*% t(n): Since Vn € N: ta(n) © t(n) and since Vn € N: t/(n) x 
ta(n) conclude Vn € N: t/(n) &* t(n) by Lem. 3. 
(ii) t/(n) &” t(n): Since Vn € N: ty(n) &” t(n) and since Vn € N: t/(n) &” 
tn(n) conclude Vn € N: t/(n) &” t(n ) by Lem. 5. 


(iii) t/(n) x? t(n): Since Vn € N: t)(n) &° t(n) and since Vn € N: t/(n) x? 
t,(n) conclude Vn € N: t!(n) ~° t(n) by Lem. 7. 
(iv) t/(n) &* t(n): Since Vn € N: Y(ta(n),tr(n), to(n)) &* t(n) and since 


),t 
Vn EN: t'(n) & Y(ta(n), tn(m), ty(n)) conclude Vn € N: t/(n) = t(n) 
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by Lem. 9. 


A.16 Proof of Thm. 17 


= >: Assume t € AN NB. Then, let t, = t, = ty = t and show 
ta € ANt, E NAty € B, Y(ta,tn, to), and t = Y(ta,tn, tp). We show 
(i) ta € A, (ii) th € N, (iii) t) € B, (iv) Y(ta, tn, ty), (v) t © ta, (vi) t &” th, 
(vii) t ~° t,, and (viii) t =" Y(ta, tn, to): 

(i) ta € A: Since t € A and t, =t, conclude t, € A. 

(ii) th € N: Since t € N and ty, = t, conclude tn € N. 


) 
) 
| 
(iv) Y (ta, tn, ty): Since ta = tn = ty have Y(ta, tn, ty) by Lem. 1. 
) 
) 
) 


(iii) tp € B: Since t € B and ty = t, conclude ty € B. 
(v) t &° ta: Since t = tg conclude t ~* t, by Lem. 3. 
(vi) t ¥" tn: Since t = t, conclude t =" t, by Lem. 5. 

(vii) ¢ ~? ty: Since t = ty conclude t x? ty by Lem. 7. 


(viii) t = ¥ Costaste): Since t = tg = tn = ty have t = V(tastayts) from 
Lem. 2 and conclude Vn € N: t(n) = Y(ta(n),tn(m), to(n)). Thus, 
have Vn € N: t(n) = Y(ta(n),tn(n), to(n)) by Lem. 9 and conclude 
t = Y(ta,tn,ty) by Def. 18. 

<=: Let t, € A, th € N, t» € B, and assume Y (tg, tn, ty), t © ta, t 2” th, 

t=? ty, and t=" Y(ta,tn, tp). We show t € ANNNB. 

e tA: Since tg € A, tn, ty € K*(S;) and Y(ta, tn, ty), conclude 3t!, € A, 
such that t/, ta, th, ©" tn, t, ? tp, and t, =" Y(ta, tn, te) by Def. 19. 
Thus, since t © tg, t=" th, t ©? ty, and t =* Y(ta, tn, te), have t, =t 
from Lem. 13 and since t/, € A conclude t € A. 

e tc N: Since tn € N, ta, ty € K*(S;) and Y(ta, tn, ty), conclude Iti, € 
N, such that t), ©" tn, t, © ta, th, ©? ty, and t), = Y(ta,tn, te) by 
Def. 20. Thus, since t ¥% tg, t ®” tn, t ¥° ty, and t x" V (Castende ys 
have t}, = t from Lem. 13 and since t), € N conclude t € N. 

e t < B: Since ty € B, ta, tn € K*(S;) and Y(ta, tn, ty), conclude se, € B, 
such that t), ~° ty, t, © ta, t, ©” tn, and t, =? Y(ta, tn, ty) by Def. 21. 
Thus, since t © ta, t ©" tn, t © ty, and t =! Y(ta, tn, tp), have t, =t 
from Lem. 13 and since t, € B conclude t € B. 
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